OpenID Connect implementation notes

Edit online

IBM® Verify continues to make security improvements to OpenID Connect implementation by following security best practices. Compatibility with the earlier versions is going to be maintained as much as possible, but you must change some items to improve security.

Changes for OpenID Connect implementation

  • Some error messages might get updated but the message ID remains the same. If you have any process that has logic that reads response messages, use the message ID instead.
  • When the authorization endpoint is hit to get an authorization code or tokens, it might redirect the user for login or multifactor authentication. In a browser, this action results in some automatic redirects. If your test automation is built around this flow, make sure to automatically follow redirects as well.
  • For endpoints that return a scope, not returning scopes or returning an empty string for the scopes are treated the same.
  • A forward slash (/) in a JSON string might not be escaped. Ensure that your JSON parser caters to both.
  • API entitlements no longer show up on the user's consent prompt. API entitlements are still granted to the tokens that are generated for that client.
  • The specification allows the use of the http scheme in the redirect_uri only if the hostname is localhost or the IP loopback literals. See OpenID Connect Core 1.0: Section 3.1.2.1. Authentication Request.
  • Query parameters are not always expected to be in the same order. When processing query parameters, use the appropriate library or have a robust regex that can find the parameter regardless of the order.

Future changes for OpenID Connect implementation

You do not need to make any immediate changes for the following items. However, it is highly recommended that you change these items to ensure that your OpenID Connect implementation follows best practice and is future-proof to changes.
  • Generally, it is more secure for POST requests to have the parameters in the request body instead of the query parameters.
  • The nonce parameter must be a cryptographically random value to make it unguessable to attackers. Make sure that it is sufficiently long and random. See Nonce Implementation Notes. A minimum of 8 characters is recommended.
  • The authorization server (IBM Verify) generates an authorization code and tokens that can be of any length, which might change in the future for security reasons. When the tokens are stored, allow at least 1024 characters for the token length. The length of tokens in JWT format such as the ID token or JWT-format access token depends on the contents of the JWT. The JWT content expands when more attributes are mapped to it.
  • The token type for bearer tokens is case-insensitive, for example "Bearer" or "bearer". Do not use any case-sensitive validation of this value.
  • When the refresh token flow is performed, new ID tokens do not have the original nonce. The nonce that is returned from the original flow is used to mitigate replay attacks on authorization request and this mitigation is not required for subsequent token requests for the refresh token flow.
  • Similar to nonce, the PKCE code verifier needs to be a cryptographically random value and unguessable. The specifications require the code verifier to be at least 43 characters long. See RFC 7636.
  • Use the state parameter to prevent cross-site request forgery by making it an unguessable value that can be validated. For example, generate a hash of the session cookie that is used to authenticate the user agent. See RFC 6749. A minimum of 8 characters is recommended.
  • The aud audience value can be a string or array. Particularly, if only one value for the audience exists, it can be a string or an array with one string.
  • The client-credential grant type is meant to generate access tokens for machine-to-machine access. Do not expect that this grant type can generate an ID token or use the access token to access the userinfo endpoint.
  • The typ (type) header parameter in the ID token is optional. The relying party must not expect a typ header parameter in the ID token.