Using External Identity Providers

Using External Identity Providers

It is possible to use an external Identity Provider to supply JWT tokens capable of accessing jiffy-applications. In order for an external IDP to provide usable JWT’s to jiffy the following criteria must be met:

  • The IDP must sign the JWT’s with an algorithm that jiffy supports (RSA / ECDSA).
  • The IDP must provide the jiffy application with a public-key for signature verification.
  • A valid user-id must exist in the jiffy application.
  • The IDP must contain a mapping of user IDP ID’s to jiffy-application internal user id’s.
  • The IDP must contain a record of the Authorization-Groups that the user should have access to.
  • The IDP must include the jiffy-specific claims in the JWT payload.
  • The IDP must supply the ‘alg’ and ‘typ’ elements in the JWT header.

Sample JWT for Jiffy Application Access

  • A user with an existing jiffy-application userID has been configured in an external IDP.
  • The user’s internal jiffy-application ID is 12, and the user has been granted access to end-points encompassed by Authorization-Groups ‘GroupA’ and ‘GroupC’.
  • The IDP is signing JWT’s with ECDSA-SHA384.

The user logs into the IDP, then attempts to access a jiffy-application resource through some means by which a jiffy-compliant JWT generated by the IDP is included in the http request-header ‘Authorization’ field:

Base64 Encoded JWT in the Authorization (compliments of jwt.io)

Sample ES384 JWT

Decoded JWT Header (Red Section)
{
  "alg": "ES384",
  "typ": "JWT"
}

Decoded JWT Payload (Purple Section)
{
  "Groups": "GroupA; GroupC",
  "email": "billthecat@1414c.io",
  "exp": 1528500904,
  "iat": 1528493704,
  "id": 12,
  "uid": 12
}

When this JWT is included in the http header of a jiffy-application request, the jiffy-application will decode the JWT header to determine the algorithm used to sign the token. Next, the application will use the appropriate public-key to verify the JWTs signature (blue section). If the application is not able to verify the signature, the request will be rejected.

Once the JWT integrity has been verified, the middleware performs the following checks before allowing the request to proceed to the entity controller method:

  • Verify that the JWT has not expired by examining the unix epoch timestamp in the ‘exp’ claim. If the system time exceeds the value contained in the ‘exp’ claim, the request will be rejected.
  • Ensure that the user-id contained in the custom ‘uid’ claim is valid by performing a lookup in the application server cache. If the user is not valid, or is not found in the cache the request is rejected. A custom claim is used here rather than the standard ‘id’ claim, as the ‘id’ claim may be expected to hold a global ID for the user.
  • Each authorization-group in the custom ‘Groups’ claim is then checked to see if it contains authorization for the requested end-point. The middleware performs this check by examining the cached values of the Authorizations assigned to each Group in the ‘Groups’ claim. If a match is found, the user is authorized to proceed and the request is allowed to enter the controller method.

Token Renewal with an External Identity Provider

Most renewal schemes employed by an external IDP can be used to renew tokens. The Jiffy application itself is not able to participate in the request for a renewal token, but the consuming application is free to interact with the IDP to renew / acquire a valid JWT when the current token is nearing expiry.