Understanding the Identity Bridge Framework

Modern authentication protocols, such as SAML and OpenID Connect (OIDC), rely heavily upon federation as the guiding principle to secure front-door authentication. Federation is an elegant approach for web-based applications to isolate authentication from the application using a trust established between the centralized identity provider (IDP) and a subscribing application. Armed with asymmetric key-based digital certificates, federation ensures that an application can securely leverage an external IDP service for authentication and free itself from the burden of handling user interaction during the authentication process.

With federation comes the concept of single sign-on (SSO). Suppose the centralized IDP has already established a secure authentication session. In that case, multiple applications can benefit from being able to single sign-on and bypass redundant login, improving user experience and reducing authentication frictions.

Limitation With Current Protocols

However, federation exhibits limitations with modern applications, especially native mobile applications. Consider the scenario of an insurance provider's mobile application using biometric authentication with a central IDP. Once a user logs in to the application, she might want to go to a banking partner web application, for instance, by clicking a link inside the application. For a seamless user experience, the expectation is to transparently log the user in with SSO to the partner web application. 

The partner web application can be configured to use the same central IDP, but federation does not work since the mobile app does not have any easy way to share an existing IDP session with the web app. The de-facto technique for web SSO is using browser cookies, something that the native mobile app can not share with the mobile's system browser. As a result, the partner application that opens in the system browser does not know there has been an existing session, and SSO does not happen. Instead, the user would have to re-authenticate to the partner app. 

A potential solution is to use a shared identifier other than a browser cookie. That approach works well for SSO between mobile apps. Since both apps reside on the same device, they can securely share a session identifier using other forms of secure storage, such as the keychain in iOS devices. There is a standard specification for native-to-native SSO with OIDC.

Unfortunately, there is no obvious way to implement SSO in a native-to-web scenario using industry standards. Often, individual applications resort to insecure ad hoc approaches.

Identity Bridge Concept

The identity bridge framework attempts to provide an architecture that applications can use to implement native-to-web SSO securely, staying close to the industry standard OIDC protocol. Since the protocol does not have a mechanism to support SSO out of the box, it needs a few additional constructs.

First, the bridge relies on the central IDP's ability to delegate authentication to another IDP. This capability is known as inbound federation. Most commercial and open-source IDPs support inbound federation. Technically, communication between the two IDPs can use any federation protocol (SAML or OIDC) independently. However, the framework recommends OIDC since the industry is increasingly adopting it for new applications.

Also, a service that we will call the Bridge service needs to be deployed. It will act as the inbound IDP communicating with the central IDP using OIDC. The bridge does not need a user interface; it will simply work as a proxy redeeming the mobile app authentication token for a web SSO session from the central IDP.

A Model Bridge Framework

Here is a model of the basic architecture for the bridge:

There is a lot to unpack here:

• The user opens the mobile app and authenticates with the central IDP.
• Central IDP issues an authentication token to the application. For OIDC, the ID Token can be considered as the authentication token.
• The user then clicks on a web link (for the target web application) inside the mobile application.
• The web link opens in the system browser. The link also contains the authentication token as a parameter.
• The web application extracts the authentication token.
• The web app application initiates an OIDC authentication with the central IDP. First, it redirects to the IDP's /authorize endpoint. It also passes the authentication token in the login_hintparameter.
• The central IDP initiates another OIDC authentication flow, with the bridge acting as the inbound IDP. It passes on the login_hint parameter, which contains the authentication token from the mobile app.
• The bridge then generates a temporary authorization_code for one-time use and redirects back to the central IDP with the authorization code.
• The central IDP makes an HTTP POST call to the bridge's /token endpoint.
• The bridge validates the authentication token obtained from the mobile app passed through the login_hint parameter in the previous step. Using information from the source authentication token, it generates a new JWT token, signs it using its private key, and returns it to the central IDP.
• Next, the central IDP calls the keys endpoint of the bridge to obtain the public key to verify the signed JWT token.
• After the JWT is validated, the central IDP creates a web session and completes the authentication process by redirecting back to the web application.

Security Considerations and Limitations

Security Risks and Challenges

Although the framework was designed using the standard OIDC protocol, it is not without its limitations.

A proxy service must be deployed and maintained by adding an additional component to the solution. The vanilla architecture does not deal with many token security aspects. If additional measures are not taken with a leaked mobile authentication token, bypassing authentication in the web application is possible.

Security Enhancements

One implementation consideration for protecting the token is not using the original authentication token from the mobile application. Mobile applications tend to have long-lived tokens, and using them to perform SSO with a web application significantly increases the risk of session compromise. For example, the following strategy can be adopted: Before starting the web SSO, obtain a separately scoped ultra-short-lived ID token from the primary IDP. Use the new token to perform SSO instead of the original token for the mobile application.

The ideal solution would be direct protocol support for native-to-web SSO. This would help avoid additional components and reduce the implementation complexity. Several promising works are underway to create an industry specification in this space.

Implementation

This section details a prototype implementation using Okta as the primary IDP.

The bridge essentially acts as an OIDC server and implements three primary APIs.

1. /authorize

This is the OIDC authorize endpoint. Okta will redirect to this endpoint using HTTP 302. The endpoint accepts the parameter login_hint, which carries the native token generated when the native app authenticates with Okta. For the prototype, the ID token issued by Okta is used as the native token.

app.get("/authorize", (request, response) => {
 customNonce = request.query.nonce;  
 response.redirect(
    request.query.redirect_uri + "?code=" + request.query.login_hint + "&state=" + request.query.state
  );
});

Okta also generates a nonce value in the response. The nonce must later be included in the token.

2. /token

OIDC token endpoint. Okta calls this endpoint to redeem the authorization code for a token. Communication occurs between Okta and the bridge. The resulting token is not reused in the application context.

app.post("/token",  async (request, response)  =>  {
  let originalClaims = jwt.decode(token);
    let claims = {};
    claims.nonce =  customNonce;
    claims.sub =  originalClaims.sub;
    claims.ver =  originalClaims.ver;
    claims.iss =  originalClaims.iss;
    claims.aud =  originalClaims.aud;
    claims.email =  originalClaims.sub;

    customKeystore = jose.JWK.createKeyStore();
    let result = await customKeystore.generate('RSA', 2048, {alg: 'RS256', use: 'sig' });
    publicKey  = result.toJSON();
    privateKeyPEM  = result.toPEM(true);
    publicKeyPEM  = result.toPEM(false);
    customJWK= jwt.sign(claims,privateKeyPEM,
      { 
        algorithm: 'RS256',
        header:
          {
            typ: 'jwt'
          }
      }
    );
    var responseData = {
      access_token: customJWK,
      token_type: "Bearer",
      expires_in: 3600,
      scope: "openid",
      id_token: customJWK,
    };
    response.send(responseData);
});

In the prototype, the implementation effectively copies the claims of the native token to create a new JWT and includes the nonce value generated during the authorization step. It then signs and sends the token to Okta. To sign the token, it generates an ephemeral key pair for a one-time use.

3. /keys

OIDC key endpoint. Okta uses this endpoint to fetch the public key of the bridge to verify the signed token issued at the /token endpoint. The implementation should return the ephemeral public key and then discard the keypair.

app.get("/keys", (request, response) => {
  let keys = {"keys":[publicKey]}
  response.send(JSON.stringify(keys));
});

Sample applications for testing: Native app and Web app.

Security Analysis

The identity bridge is transparent to various applications. It communicates only with the primary IDP using OIDC, which is a secure federation protocol.

The bridge must send a signed token to the IDP. It generates ephemeral key pairs for signing. Because every authentication is aided by a unique random keypair, a complex key management is not required. The bridge must ensure that the key pair is discarded after use or is in a failure condition.

The authentication token used should have a sufficiently small value to reduce the potential for token leakage and guard against token replay attack. 

To further reduce the risk of token leakage, another idea is to use a very short duration token from the primary IDP generated just before initiating the SSO, instead of using the primary authentication token from the native application.

Additionally, the bridge should be configured to accept requests only from whitelisted IPs related to the primary IDP.

Real-World Use Cases

Let us look at a few real-world scenarios in which native-to-web SSO flow is common. 

Corporate Portal

A corporate mobile application can have links to authorized applications that are web-based and open in a system browser. After employees log into their corporate web portal, they typically single sign on to the applications they are authorized for. To provide a similar feature when they access the portal through the company's mobile application, a native-to-web SSO flow is required, particularly for web-based applications. 

Online Travel Agency

The mobile app for an online travel agency can have web links to its partner airlines and hotels. Customers can then log in to the mobile app and click on their preferred airline or hotel to directly access and manage their bookings from their respective websites.

Healthcare

The mobile app for a medical provider or hospital can allow access to the web-based patient portal (for example, Epic MyChart) without the patient needing to be authenticated in the patient portal again.

Streaming and E-Commerce 

Many consumer-facing streaming and e-commerce applications provide core features through mobile applications such as streaming videos or allowing consumer shopping. They redirect users to the web interface for other features such as account and subscription management.  native-to-web SSO will allow consumers to switch to the web interface without re-authentication, thereby improving the user experience.

Vendor Portal

Similar to corporate portals, organizations typically create mobile applications for B2B portals, such as vendor applications. Vendors can have access to several web-based applications through the portal and hence will benefit from the native-to-web SSO ability.

Conclusion

Today, applications increasingly use different platforms and devices to provide flexibility to users and allow them to access an application from any place and device. The idea is to bring the applications close to users and allow them to access them from any digital platform that they might be using. 

Properly authenticating and authorizing users without disrupting their experience and productivity in such an environment is critical. The OIDC bridge complements web-to-web federation and native-to-native SSO standards to provide authentication and SSO services across applications in all possible devices and platforms.