This document discusses the use of JSON Web Tokens (JWTs) for authorization. It provides an introduction to JWTs, describing their compact format and how they can be signed and contain claims. It then gives examples of using JWTs in OpenID Connect flows and for third-party authorization. Finally, it discusses some future use cases around hyper-scale authorization across many autonomous services and devices.

1. © 2016 ForgeRock. All rights reserved.
Authorization
Using JWTs
Simon Moffatt
Principal Engineer @ ForgeRock
@SimonMoffatt
http://www.simonmoffatt.com
Blogger @ http://www.theidentitycookbook.com

2. © 2016 ForgeRock. All rights reserved.
Contents
Introduction to JWT
Claims in OIDC id_token
3rd
Party Authorization
Future Use Cases

3. © 2016 ForgeRock. All rights reserved.
Introduction to JWT – Part 1
l
Integrate – but with caution
l
Correlate to known data
“JSON Web Token (JWT) is a compact, URL-safe means of representing
claims to be transferred between two parties. The claims in a JWT
are encoded as a JSON object that is used as the payload of a JSON
Web Signature (JWS) structure or as the plaintext of a JSON Web
Encryption (JWE) structure, enabling the claims to be digitally
signed or integrity protected with a Message Authentication Code
(MAC) and/or encrypted.” - RFC7519 - https://tools.ietf.org/html/rfc7519

Self Contained

Signed and/or encrypted

JSON formatted

Lots of implementation libs

Lightweight

4. © 2016 ForgeRock. All rights reserved.
Introduction to JWT – Part 2
l
Integrate – but with caution
l
Correlate to known data
Header
Payload
Signature

5. © 2016 ForgeRock. All rights reserved.
Introduction to JWT – Part 2
l
Integrate – but with caution
l
Correlate to known data
Header
Payload
Signature
{
typ: "JWT",
alg: "HS256"
} {
"expiryTime":14688417398
58,"UserId":"smoff","AuthLe
vel":"0","Locale":"en_GB","
HostName":"127.0.0.1",
...}
fvD2FTo57RZp7MdoH
7vyVBmS_533TXriKNi
bawEf9SY

6. © 2016 ForgeRock. All rights reserved.
What’s the problem we are trying to solve?

“Stateful” - server side logic and
verification

Traditional authorization landscape

Scale limitations

Card is granted to individual

Association and verification completed

Card presented to shop to purchase

Shop communicates to issuer to verify
funds, association etc

Cash is initially granted to individual

Needs to be kept safe as no
secondary factor – bearer token!

Can be exchanged without going
back to bank – just verify the note
locally

“Stateless” - client side logic

Modern mesh based interactions

Offline verification

Scaleable

7. © 2016 ForgeRock. All rights reserved.
What’s the problem we are trying to solve?

“Stateful” - server side logic and
verification

Traditional authorization landscape

Scale limitations

Card is granted to individual

Association and verification completed

Card presented to shop to purchase

Shop communicates to issuer to verify
funds, association etc

Cash is initially granted to individual

Needs to be kept safe as no
secondary factor – bearer token!

Can be exchanged without going
back to bank – just verify the note
locally

“Stateless” - client side logic

Modern mesh based interactions

Offline verification

Scaleable

8. © 2016 ForgeRock. All rights reserved.
Example with OpenID Connect
Can be a JWT
Can also be a JWT...
Can overload
JWT in order to
negate steps 8 &
9...

9. © 2016 ForgeRock. All rights reserved.
Computery
Demo Stuff https://commons.wikimedia.org/wiki/File:IBM_Electronic_Data_Processing_Machine_-_GPN-2000-001881.jpg
Based on http://www.theidentitycookbook.com/2015/12/scripted-openid-connect-claims-and.html

10. © 2016 ForgeRock. All rights reserved.
Example with OpenID Connect - config

11. © 2016 ForgeRock. All rights reserved.
Example with OpenID Connect – getting the tokens

12. © 2016 ForgeRock. All rights reserved.
Example with OpenID Connect – id_token introspection
Extended
Profile scope
Profile scope
Email
scope
Entitlements scope

13. © 2016 ForgeRock. All rights reserved.
Example with 3rd
Party Authorization

Leverage a token generated by a 3rd party / separate operational domain

Have resources protected via centralised Policy Decision Point

Contact the Policy Decision Point before granting access

Just-in-Time authorization – don’t need up front user knowledge, just meta data
exchange
“Like posting a tweet using your Facebook account without
having a Twitter profile!”

14. © 2016 ForgeRock. All rights reserved.
Computery
Demo Stuff https://commons.wikimedia.org/wiki/File:IBM_Electronic_Data_Processing_Machine_-_GPN-2000-001881.jpg
Based on http://www.theidentitycookbook.com/2016/05/federated-authorization-using-3rd-party.html

15. © 2016 ForgeRock. All rights reserved.
Example with 3rd
Party Authorization - config

16. © 2016 ForgeRock. All rights reserved.
Example with 3rd
Party Authorization – get the JWT
Trust
Correct Use
User Meta Data

17. © 2016 ForgeRock. All rights reserved.
Example with 3rd
Party Authorization – response
Access Granted Invalid Signature /
Untrusted IDP

18. © 2016 ForgeRock. All rights reserved.
Future use cases...
The very immediate future will see
an increased number of devices,
API’s, services and interactions
that will need authX functions
applying to them
API
Device
User

19. © 2016 ForgeRock. All rights reserved.
Future use cases...
UC#1 – Hyper scale authorization for millions of users requesting authX
from any autonomous identity service
UC#2 – A protected application or service wants to allow access to a user or
other service, but is often “offline” and can’t communicate to central PDP
UC#3 – A pin & paired internet connected washing machine wants to
communicate to a smart metre, which in turn wants to communicate with the
water boiler – all from different operational domains and highly federated

20. © 2016 ForgeRock. All rights reserved.
Thank You