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 mean there is either no current mitigation 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 accidentally forwarding these user credentials.

2.1.1. Authorization code grant

Strivacity checks the entropy of nonce values for the PKCE challenge and the OpenID Connect nonce.
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 as specified in [RFC6749] to determine the resource server it wants to access.
Strivacity restricts access tokens to certain resources and actions on resource servers or resources by the 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 ensure 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 be redirected to that endpoint with an error message stating that HTTP is not allowed.
Strivacity Metadata Endpoint, jwks_uri Endpoint, and Dynamic Client Registration Endpoint support the use of Cross-Origin Resource Sharing (CORS).
- Strivacity supports CORS at the authorization endpoint only for native clients that call an authentication endpoint from JavaScript 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 validated 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 supports 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 is a code_challenge in the authorization request for which this code was issued, Strivacity provides a valid code_verifier in the token request.

4.11 Open redirection

Strivacity always authenticates the user first and, except for the silent authentication use case, prompts the user for credentials when needed, before redirecting the user.
Strivacity only automatically redirects 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 can be configured to determine, based on a risk assessment, whether to issue refresh tokens to a certain client.
Strivacity provides a configurable refresh token timeout.

4.15. Client impersonating resource owner

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

4.16 Clickjacking

Strivacity mitigates clickjacking attacks by utilizing frame-busing JavaScript

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.