JWT Use Cases

This post explores the equivalent JWT use cases corresponding to the five SAML2 use cases that were explored earlier in this series. We had to build up our tool set to get to this point — including exploring JWT, OAuth2, OpenID Connect, and the supporting specs. To be ready for this moment, we’ve explored:

SAML2 vs JWT: Understanding JSON Web Token (JWT)

SAML2 vs JWT: Understanding OAuth2

Understanding OpenID Connect Series

When To Use Which (OAuth2) Grants and (OIDC) Flows

OpenID Connect Logout

The SAML Use Cases introduced the specs and mechanics needed to make the use cases work as we hit each topic. For the JWT Use Cases, the leg work was done ahead of time. Why the different approach? Two reasons. First, the technology is much newer than SAML2 and its install base isn’t nearly as large. Second, the specifications are laid out differently and related differently; this approach has allowed me to dig deeply into each of JWT, OAuth2, and OIDC. It took longer to get here, but now that we are, the use case descriptions will be more concise.

Application SSO

In the SAML2 use cases, we explored traditional web application SSO only. In the Understanding OpenID Connect series and When To Use Which (OAuth2) Grants and (OIDC) Flows post SSO for multiple application types are explored.

SP Initiated SSO — OIDC

SP initiated Single Sign On (SSO) is described in the “When To Use Which (OAuth2) Grants and (OIDC) Flows” blog post for several different application types.

IdP Initiated SSO — OIDC

IdP Initiated SSO is the equivalent of what the OIDC spec describes as third-party login. This is described in my earlier “Understanding OpenID Connect Part 3” post.

SOAP Web Services + JWT

SOAP Web Services using JWT haven’t been explicitly discussed in this series, but we have described all the mechanisms needed to make it happen in a spec-defined manner. The goal is to authenticate a SOAP request using a JWT token in place of a SAML2 assertion.

The method of doing this is described in the Binary Security Token Sectionof the WS-Security v1.1 specification. Now, there is no specification that officially describes what value should be used for the /wsse:BinarySecurityToken/@ValueType attribute when the BST contains a. JWT token; however, if IBM can use proprietary values that are not defined in any specification for LTPA2 tokens, then we can define a value for JWTs so long as all system actors involved understand and can process that value.

Suppose we have the following JWT:

eyJhbGciOiJSUzI1NiJ9.eyJhIjoiYiIsImMiOiJkIiwiZSI6MX0.CNMaYaDGU3ZhFV1ve6p3sAdYXhEklej8DVIAMqIWCkpNmT6Jp7iigcndXwH5q3WQFHiswgIQU5-_-4rV3jKGptCROmEyWPW8_elhYH1apzAyjOjyZ55ygv37xKHzIFhixzAwmXlAv4pfD4lVelYWVNOSN7REA0QJeCy2vKdqZ5cjqCXQ1lkQUlzOE7dpuNoAkhAhAJJ8HaamFKy7Gl7uwmqbIr-dVYv21d_9O7mO26n0gy3zWXD2nJDxU5Mzl2pZd8-sFvUr9Kmp_YkeRMh4bSe0fr1Uc_YgkjpmYUyu7kaxRWTbAdJ3GwqWFMUDiyfhHdzvZPZyU4VkWreimoydMA

See the earlier Understanding JSON Web Token post for the details. While the individual components of the JWT are already Base64URL encoded, the whole structure is not technically base64-encoded. So, the base64-encoded JWT would look like:

ZXlKaGJHY2lPaUpTVXpJMU5pSjkuZXlKaElqb2lZaUlzSW1NaU9pSmtJaXdpWlNJNk1YMC5DTk1hWWFER1UzWmhGVjF2ZTZwM3NBZFlYaEVrbGVqOERWSUFNcUlXQ2twTm1UNkpwN2lpZ2NuZFh3SDVxM1dRRkhpc3dnSVFVNS1fLTRyVjNqS0dwdENST21FeVdQVzhfZWxoWUgxYXB6QXlqT2p5WjU1eWd2Mzd4S0h6SUZoaXh6QXdtWGxBdjRwZkQ0bFZlbFlXVk5PU043UkVBMFFKZUN5MnZLZHFaNWNqcUNYUTFsa1FVbHpPRTdkcHVOb0FraEFoQUpKOEhhYW1GS3k3R2w3dXdtcWJJci1kVll2MjFkXzlPN21PMjZuMGd5M3pXWEQybkpEeFU1TXpsMnBaZDgtc0Z2VXI5S21wX1lrZVJNaDRiU2UwZnIxVWNfWWdranBtWVV5dTdrYXhSV1RiQWRKM0d3cVdGTVVEaXlmaEhkenZaUFp5VTRWa1dyZWltb3lkTUE=

A SOAP WS-Security <Security> element would look something like the following:

<S11:Envelope xmlns:S11=”…” xmlns:wsse=”…”>
  <S11:Header>
    …
    <wsse:Security>
      <wsse:BinarySecurityToken xmlns:oidc=”http://spec.levvel.io/identity/OIDC/" EncodingType=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#BinarySecurityToken” ValueType=”wsst#JWT”>ZXlKaGJHY2lPaUpTVXpJMU5pSjkuZXlKaElqb2lZaUlzSW1NaU9pSmtJaXdpWlNJNk1YMC5DTk1hWWFER1UzWmhGVjF2ZTZwM3NBZFlYaEVrbGVqOERWSUFNcUlXQ2twTm1UNkpwN2lpZ2NuZFh3SDVxM1dRRkhpc3dnSVFVNS1fLTRyVjNqS0dwdENST21FeVdQVzhfZWxoWUgxYXB6QXlqT2p5WjU1eWd2Mzd4S0h6SUZoaXh6QXdtWGxBdjRwZkQ0bFZlbFlXVk5PU043UkVBMFFKZUN5MnZLZHFaNWNqcUNYUTFsa1FVbHpPRTdkcHVOb0FraEFoQUpKOEhhYW1GS3k3R2w3dXdtcWJJci1kVll2MjFkXzlPN21PMjZuMGd5M3pXWEQybkpEeFU1TXpsMnBaZDgtc0Z2VXI5S21wX1lrZVJNaDRiU2UwZnIxVWNfWWdranBtWVV5dTdrYXhSV1RiQWRKM0d3cVdGTVVEaXlmaEhkenZaUFp5VTRWa1dyZWltb3lkTUE=</wsse:BinarySecurityToken>
    </wsse:Security>
    …
  </S11:Header>
  …
</S11:Envelope>

Microsoft uses a more meaningful ValueType attribute value for a JWT as a BST:

urn:ietf:params:oauth:token-type:jwt or JWT

The first value that Microsoft supports in this scenario is defined by the JSON Web Token spec.

API Invocation + JWT

This is described in the OAuth2 blog post and Understanding OIDC series. Let’s call the official example used here the details laid out in the latter.

To make this be comparable to the SAML2 Use Case, the OAuth2 access token should be a JWT. From a strictly technical perspective, the access token could be an opaque token or some other token type and the UserInfo endpoint could be used to retrieve any claims that a system actor may need.

Single Logout — OIDC

Single Logout is described in the OpenID Connect Logout blog post.

A JWT token is used in the back-channel communication scenarios. The logout use cases are defined by the OIDC family of specs.

Summary

So, that gives us the equivalent JWT use cases to the original SAML2 use cases. In the next and final post in this series, the differences between SAML2 and JWT will be given.

Image: Lock / Tjook (@xtjook)