Strivacity’s CIAM platform aligns with the OAuth 2.0 Security Best Current Practice (RFC 9700), ensuring secure-by-default behavior for all OAuth and OpenID Connect (OIDC) integrations.

The following describes how Strivacity adheres to these best practices. The document is structured using the same structure as the RFC 9700 document. Missing sections means there is either no current migitation or the recommendations to not pertain to authorization servers.

2.1 Protecting redirect-based flows

Strivacity uses exact string matching except for port numbers in localhost redirection URIs of native apps
Strivacity does not expose URLs that forward the user's browser to arbitrary URIs obtained from a query parameter (open redirectors)
Strivacity, when redirecting a request potentially containing user credentials, avoids forwarding these user credentials accidentally

2.1.1. Authorization code grant

Strivacity makes a reasonable effort at detecting and preventing the use of constant values for the PKCE challenge or OpenID Connect nonce by checking entropy for nonce values.
Strivacity supports PKCE [RFC7636]
Strivacity detects and prevents the use of constant values for the PKCE challenge or OpenID Connect nonce
Strivacity enforces the correct usage of code_verifier at the token endpoint when a client sends a valid PKCE code_challenge parameter in an authorization request
Strivacity mitigates PKCE downgrade attacks by ensuring that a token request containing a code_verifier parameter is accepted only if a code_challenge parameter was present in the authorization request
Strivacity provides a way to detect support for PKCE via a /.well-known/openid-configuration URI

2.3 Access token privilege restriction

Strivacity utilizes the parameters scope and resource as specified in [RFC6749] and [RFC8707], respectively, to determine the resource server they want to access
Strivacity restrics access tokens to certain resources and actions on resource servers or resources by authorization server by associating the access token with the respective resource and actions

2.5 Client authentication

Strivacity enforces client authentication to establish a process for issuance/registration of credentials for clients and ensuring the confidentiality of those credentials

2.6 Other recommendations

Strivacity publishes OAuth Authorization Server Metadata according to [RFC8414] (/.well-known/openid-configuration) and clients can make use of this Authorization Server Metadata to configure themselves
Strivacity does not allow clients to influence their client_id or any other claim that could cause confusion with a genuine resource owner
Strivacity does not allow redirection URIs that use the http scheme except for native clients that use loopback interface redirection
- Strivacity does allow http redirect uris to be configured, but the flow will get redirected to that endpoint with an error message stating http is not allowed.
Strivacity Metadata Endpoint, jwks_uri Endpoint, and Dynamic Client Registration Endpoint supports the use of Cross-Origin Resource Sharing (CORS)
- Strivacity support CORS at the authorization endpoint only for native clients that are calling an authentication endpoint from JS without a redirect

4. Attacks and mitigations

4.1 Insufficient Redirection URI Validation

Strivacity uses exact string matching to ensure the two redirect URIs are equal

4.2 Credential leakage via referer headers

Authorization codes are invalidated validate by Strivcaity after their first use at the token endpoint

4.4 Mix-up attacks

Strivacity sends its issuer identifier in the authorization response to the client

4.5 Authorization code injection

Strivacity supports PKCE
Strivacity support Nonce

4.6 Access token injection

See section 2.1 above

4.7 Cross-site request forgery

Strivacity provides a way to detect support for PKCE via the /.well-known/openid-configuration URI, as specified in [RFC8414]

4.8 PKCE downgrade attack

Strivacity checks whether a code challenge is contained in the authorization request and binds this information to the code that is issued
When a code arrives at the token endpoint, and there was a code_challenge in the authorization request for which this code was issued, there Strivacity provides a valid code_verifier in the token request

4.11 Open redirection

Strivacity always authenticates the user first and, with the exception of the silent authentication use case, prompt the user for credentials when needed, before redirecting the user
Strivacity only automatically redirect the user agent if it trusts the redirection URI

4.12 307 Redirect

Strivacity does not use the HTTP 307 status code for redirection

4.14 Refresh token protection

Stricity determines, based on a risk assessment, whether to issue refresh tokens to a certain client
Strivacity provides a configurable re-fresh token timeout

4.15. Client impersonating resource owner

Strivacity does not allow clients to influence their client_id or any other claim

4.17 Attacks on in-browser communication flows

Strivacity uses exact string matching as described in Section 4.1.3
Strivacity sends postMessages to trusted client receiver origins