Skip to main content

Overview of Open Authentication

Open OS user authentication is implemented with OpenID Connect (OIDC) and OAuth 2 with Bearer Token. The token is in JWT format and contains access data (token type and private key) and some user information, including email. The JWT token is issued and validated through Keycloak.

Authentication Flow​

The Wpp Open Application fetches context, authenticates the user with the help of a JWT, and validates the user's token with a backend service before granting access. The JWT is downloaded, validated, and verified in multiple steps, ensuring only authorised users can access the app.

Authentication of Users​

  1. When the user launches the App the OS passes the context object. The Application fetches the context for the user session from the parent app, initiating the authentication process.
  2. Use context.osApi.getAccessToken() ; to return the JWT token.
  3. The app can make a request to fetch the security certificate from Open.
  4. The application then verifies the JWT using the certificate.
  5. If the Certificate verifies correctly, allow user to access the app.

Application-specific Re-authentication​

After validating the user you can use your own authentication system within your back-end to revalidate the user and issue a new JWT for that user’s session.

Authorization​

Authorization is handled by Alpha Zulu. It is recommended to fetch the current user’s permission and validate if the user has access to the page and resources they are requesting within the app.

Federating IDPs with Okta​

WPP Open uses Okta to authenticate internal WPP users and federate external Identity Providers (IDPs) for clients.

note

Although WPP Open federates IDPs, it does not function as an IDP itself.

JWT Issuance and Access Token Handling​

After a successful authentication, WPP Open issues its own JWT and products integrating with Open should utilise this token. Applications integrating with WPP Open should use this token for secure data access. The access token is provided in the context for native applications and can be passed to embedded applications via postMessage.

note

The access token is provided in the context object for all application types - for more details on application types and the context object, please refer to the Product Context documentation.

Token Validation​

Each application should validate the token to verify its authenticity and prevent unauthorised access. To validate the JWT:

  1. Retrive the jwks_url from

The public keys change infrequently and thus can be cached locally to perform local validation.

  1. Validate the JWT: Use the JWKS to verify the token’s signature, ensuring its legitimacy. This process involves parsing the certificate and cryptographically validating the token.
note
  • After downloading a JWKS certificate, applications can confirm the token’s authenticity without needing to retrieve the certificate for each request.
  • Most frameworks are equipped with libraries that facilitate verification of OIDC tokens.

Token Refresh Process​

Tokens have a predefined validity period, after which they need refreshing. WPP Open’s backend manages the refresh, allowing applications to continue accessing resources without user interruption.

note

As OS handles the refresh, apps must obtain the token from the context each time they need to use it.