FAQ

ID Token does not include claims other than sub

Only response types that do not end up with an access_token (so, response_type=id_token) have end-user claims other than sub in their ID Tokens. This is the Core 1.0 spec behaviour. Read it you’ll see requesting claims through the scope parameter only adds these claims to userinfo unless the response_type is id_token in which case they’re added there. All other response types have access to the userinfo endpoint which returns these scope-requested claims. The other option is to allow clients to request specific claims from a source they expect it in via the claims parameter.

But, if you absolutely need to have scope-requested claims in ID Tokens you can use the conformIdTokenClaims configuration option.

Why does my .well-known/openid-configuration link to http endpoints instead of https endpoints?

Your authorization server is behind a TLS terminating proxy, tell your Provider instance to trust the proxy headers. More on this in Trusting TLS offloading proxies

My client_secret with special characters is not working

You’re likely using client_secret_basic client authentication and the oidc-provider is actually exhibiting conform behaviour. It’s likely a bug in your client software - it’s not encoding the header correctly.

client_secret_basic is not 100% basic http auth, the username and password tokens are supposed to be additionally formencoded.

A proper way of submitting client_id and client_secret using client_secret_basic is Authorization: base64(formEncode(client_id):formEncode(client_secret)) as per https://www.rfc-editor.org/rfc/rfc6749.html#section-2.3.1 incl. https://www.rfc-editor.org/rfc/rfc6749.html#appendix-B

Example:

const client_id = "an:identifier";
const client_secret = "some secure & non-standard secret";

// After formencoding these two tokens
const encoded_id = "an%3Aidentifier";
const encoded_secret = "some+secure+%26+non%2Dstandard+secret";

// Basic auth header format Authorization: Basic base64(encoded_id + ':' + encoded_secret)
// Authorization: Basic YW4lM0FpZGVudGlmaWVyOnNvbWUrc2VjdXJlKyUyNitub24lMkRzdGFuZGFyZCtzZWNyZXQ=

So essentially, your client is not submitting the client auth in a conform way and you should fix that.

I’m getting a client authentication failed error with no details

Every client is configured with one of 7 available token_endpoint_auth_method values and it must adhere to how that given method must be submitted. Submitting multiple means of authentication is also not possible. Authorization server operators are encouraged to set up listeners for errors (see events.md) and deliver them to client developers out-of-band, e.g. by logs in an admin interface.

function handleClientAuthErrors({ headers: { authorization }, oidc: { body, client } }, err) {
  if (err.statusCode === 401 && err.message === "invalid_client") {
    // console.log(err);
    // save error details out-of-bands for the client developers, `authorization`, `body`, `client`
    // are just some details available, you can dig in ctx object for more.
  }
}
provider.on("grant.error", handleClientAuthErrors);
provider.on("introspection.error", handleClientAuthErrors);
provider.on("revocation.error", handleClientAuthErrors);

Refresh Tokens

I’m not getting refresh_token from token_endpoint grant_type=authorization_code responses, why?

Do you support offline_access scope and consent prompt? Did the client request them in the authentication request?

Yeah, still no refresh_token

Does the client have grant_type=refresh_token configured?

Aaaah, that was it. (or one of the above if you follow Core 1.0#OfflineAccess)

The Authorization Server MAY grant Refresh Tokens in other contexts that are beyond the scope of this specification. How about that?

Yeah, yeah, see configuration

Password Grant Type, ROPC

If you need it today something’s wrong!

ROPC falls beyond the scope of what the library can do magically on its own having only accountId and the claims, it does not ask for an interface necessary to find an account by a username nor by validating the password digest. Custom implementation using the provided registerGrantType API is simple enough if ROPC is absolutely required.

How to display, on the website of the authorization server itself, if the user is signed-in or not

const ctx = provider.createContext(req, res);
const session = await provider.Session.get(ctx);
const signedIn = !!session.accountId;

Client Credentials only clients

Client Credential clients don’t use the authorization endpoint, so set response_types to an empty array. The redirect_uris will default to [] automatically.

{
  // ... rest of the client configuration
  response_types: [],
  grant_types: ['client_credentials']
}

Resource Server only clients (e.g. for token introspection)

Resource server clients don’t use any grants or the authorization endpoint, so set response_types to an empty array. The redirect_uris will default to [] automatically.

{
  // ... rest of the client configuration
  response_types: [],
  grant_types: []
}