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

[TheZipCreator]

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]

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": "testuser@example.com"}

  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. 😄