Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do you add a specific user login to the standalone server? #820

Open
TheZipCreator opened this issue Mar 14, 2025 · 1 comment
Open

Comments

@TheZipCreator
Copy link

Hello, I'm currently making an OAuth client implementation and I want to use the standalone server for testing. However, I'm not exactly sure how to tell the server that a user exists (for example with username foo and password bar). I tried looking at OAuthConfig and other classes but I couldn't find how I'm supposed to do it (perhaps I'm missing something).

Could I have some guidance on how to do this?

@micolous
Copy link

micolous commented Mar 20, 2025

The short answer is that mock-oauth2-server has no idea about users, so there's no way to "register" them.

If you set "interactiveLogin": true in your stand-alone server configuration, when your application directs the browser to the /authorize endpoint (for the Auth Code flow), you should get a login form with two fields:

  • "Enter any user / subject": This is the sub claim. This is an immutable and opaque user identifier, which has no relation to their "username", "name", or any other personally-identifiable information.

    It's common for identity providers to put a UUID here.

  • "Optional claims value": These are added to the access_token and id_token when your application fetches the token. OpenID Connect Core has a list of standard claims; but if you want something to copy:

    {"preferred_username": "testuser", "name": "Test User", "email": "[email protected]"}

    Every field is optional. You should probably look at what your "real" identity provider supplies here, and build something from there. mock-oauth2-server does not take into account the requested scopes.

It's possible to script filling in those fields in browser-based automated tests (eg: Playwright) or with a manual HTTP POST.


Side note, for using these claims in your application: the combination of the sub of iss values are the only stable unique user identifiers. All other fields, including email, name, preferred_username are not guaranteed to be unique or fixed, and some identity providers may allow users to change these fields on their own (and in some cases, without verification!). If your application relies on unstable claims to uniquely identify users, your application has a security bug – not the identity provider!

I mention this as it is a very common security bug, even from security software vendors. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants