OIDC token or SAML2 response generation step

After a customer successfully authenticates and meets all policy requirements, Strivacity generates and provides the necessary authentication and authorization credentials in the form of OpenID Connect (OIDC) tokens or SAML 2.0 assertions. These credentials allow applications to establish customer sessions and grant access based on the customer’s identity and permissions.

OIDC/OAuth2 token generation

For applications using OpenID Connect (OIDC) or OAuth 2.0, Strivacity issues authentication and authorization tokens at the end of the login process. These tokens are sent to the application, also known as the Relying Party (RP), and include:

• ID Token – Contains customer identity claims (such as name, email, and subject identifier).
• Access Token – Grants access to protected resources.
• Refresh Token (if requested) – Enables obtaining new access tokens without requiring the customer to re-authenticate.

These tokens are typically returned via:

• A redirect URI (for authorization code flows).
• A backchannel response (for hybrid flows).

The RP is responsible for validating the tokens by checking the signature, issuer, audience, and expiration time before establishing a session or granting access.

Customizing OIDC tokens

The claims included in the ID token depend on the Claims Dialect configured for the OIDC client. Strivacity also supports token enrichment through the Before ID token generation hook, allowing for additional customization.

SAML 2.0 assertion generation

For application using SAML 2.0Strivacity generates a SAML assertion at the end of the login process. The assertion is an XML-based security token that provides authentication and authorization details about the customer, including:

• Customer identity (NameID).
• Attributes (email, roles, etc.).
• Authentication details (e.g., time of authentication, method used).

The assertion is typically signed and may be encrypted to ensure security. It is sent to the Service Provider (SP) through a SAML response, usually via:

• HTTP POST – Automatically submitted via the browser for SP-initiated single sign-on (SSO).

The SP validates the SAML assertion by checking the signature, expiration time, and issuer details before granting the customer access. Once validated, the SP establishes a session, allowing the customer to use protected resources without needing to reauthenticate until the session expires.

Customizing SAML assertions

The claims included in the SAML assertion depend on the Claims Dialect configured for the SAML 2.0 client. Strivacity supports assertion enrichment through the Before SAML2 assertion generation hook, allowing customization of the assertion content.