The document discusses OpenID Connect (OIDC) focusing on advanced concepts like single sign-on (SSO), single sign-out, and token types including self-contained and reference tokens. It highlights the mechanisms for integrating and managing user authentication across multiple applications and provides insights into token exchange approaches for better security and user experience. Additionally, resources for further learning and demos on implementation are shared.

1. KEVINDOCKX
https://www.kevindockx.com
OPENID CONNECT
IN-DEPTH
In this session, you’ll learn about
less-than-obvious OIDC
approaches and use cases

2. KEVINDOCKX
MARVIN
HI, I’M KEVIN
@KevinDockx
https://www.kevindockx.com
https://github.com/KevinDockx
Freelance solution architect
focused on APIs and security
Microsoft MVP
Pluralsight Author
2

3. KEVINDOCKX
MARVIN
COMING UP
SSOn/SSOut
Reference tokens & token revocation
API to API communication on behalf of the user
3

4. KEVINDOCKX
MARVIN
Given multiple
applications, using the
same set of credentials, a
user should only provide
these credentials once
4

5. KEVINDOCKX
MARVIN
SINGLE SIGN-ON
id_token
Application A
IDP
id_token
Application B

6. KEVINDOCKX
MARVIN
DEMO TIME Time to dive into code
6

7. KEVINDOCKX
MARVIN
SINGLE SIGN-OUT
Application A
IDP
Application B

8. KEVINDOCKX
MARVIN
SINGLE SIGN OUT: SPECIFICATIONS
8
Server-side
Front-Channel Logout
https://openid.net/specs/openid-connect-frontchannel-1_0.html
Back-Channel Logout
https://openid.net/specs/openid-connect-backchannel-1_0.html

9. KEVINDOCKX
MARVIN
SINGLE SIGN-OUT (SERVER, FRONT CHANNEL)
Application A IDP
Application B
sign-out endpoint
sign-out endpoint
iframe (hidden)
logged out
iframe (hidden)

10. KEVINDOCKX
MARVIN
SINGLE SIGN OUT: SPECIFICATIONS
10
Client-side
OIDC Session Management (also front-channel)
https://openid.net/specs/openid-connect-session-1_0.html

11. KEVINDOCKX
MARVIN
SINGLE SIGN-OUT (USER AGENT, FRONT CHANNEL)
Application B IDP
Application C
(user agent based)
sign-out endpoint
iframe (hidden)
logged out
hidden iframe polling
check_session_iframe
(URI from discovery
document)

12. KEVINDOCKX
MARVIN
DEMO TIME Time to dive into code
12

13. KEVINDOCKX
MARVIN
SELF-CONTAINED VS REFERENCE TOKENS
13
JWT (self-contained) Reference token
{
"nbf": 1568970856,
"exp": 1568974456,
"iss": "https://localhost:44391",
"aud": [ "https://localhost:44391/
resources", "api1"],
"client_id": "webclient",
"sub": "818727",
"email": "AliceSmith@email.com",
"scope": ["openid", "email",
"api1"]
}
fe1370fab9e1c7f9edd0d85427f98e6da2fb28d27689fd030fc0042c56
d6e406

14. KEVINDOCKX
MARVIN
SELF-CONTAINED VS REFERENCE TOKENS
14
A self-contained token (JWT) is a protected data structure
with claims and an expiration
• Once the API knows about the public key to verify the signature, no
additional communication with the IDP is required
• A self-contained token potentially grants access for as long as that
token hasn’t expired
• There is no mechanism to revoke self-contained tokens

15. KEVINDOCKX
MARVIN
SELF-CONTAINED VS REFERENCE TOKENS
15
A reference token is an identifier for the actual token
• It references a grant result (token) stored at IDP level
• Remove the grant result to revoke access ad hoc
• It requires communication with the IDP on each request
• The communication requirement is often tackled by caching the grant
result

16. KEVINDOCKX
MARVIN
DEMO TIME Time to dive into code
16

17. KEVINDOCKX
MARVIN
Use reference tokens for
tokens that leave the
company walls
17

18. KEVINDOCKX
MARVIN 18
Api1
{
sub: “kevin”,
aud: [“api1”]
}
Client
API TOAPIACCESS ON BEHALF OF THE USER

19. KEVINDOCKX
MARVIN
API TOAPIACCESS ON BEHALF OF THE USER
19
Api1
{
sub: “kevin”,
aud: [“api1”]
}
Client
Api2

20. KEVINDOCKX
MARVIN
API TOAPIACCESS ON BEHALF OF THE USER
20
Api1
{
sub: “kevin”,
aud: [“api1”]
}
Client
Api2
{
aud: [“api2”]
}

21. KEVINDOCKX
MARVIN
API TOAPIACCESS ON BEHALF OF THE USER
21
Api1
{
sub: “kevin”,
aud: [“api1”, “api2”]
}
Client
Api2
{
sub: “kevin”,
aud: [“api1”, “api2”]
}

22. KEVINDOCKX
MARVIN
API TOAPIACCESS ON BEHALF OF THE USER
22
Api1
{
sub: “kevin”,
aud: [“api1”, “api2”]
}
Client
Api2
{
sub: “kevin”,
aud: [“api1”, “api2”]
}

23. KEVINDOCKX
MARVIN
API TOAPIACCESS ON BEHALF OF THE USER
23
Api1
{
sub: “kevin”,
aud: [“api1”]
}
Client
Api2
{
sub: “kevin”,
aud: [“api2”]
}

24. KEVINDOCKX
MARVIN
API TOAPIACCESS ON BEHALF OF THE USER
24
Api1
{
sub: “kevin”,
aud: [“api1”]
}
Client
Api2
{
sub: “kevin”,
aud: [“api2”]
}

25. KEVINDOCKX
MARVIN
API TOAPIACCESS ON BEHALF OF THE USER
25
We need a custom flow
• OAuth2 was built with extensibility in mind
Token Exchange (proposed standard)
• https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-19
• Describes how to safely exchange tokens for other tokens, including
how to request tokens for employing impersonation and delegation
• We can use impersonation semantics for this – we’re simply
“impersonating” our self

26. KEVINDOCKX
MARVIN
API TOAPIACCESS ON BEHALF OF THE USER
26
POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTA2MDAsIm5iZiI6MTQ0MTkwOTAwMCwic
3ViIjoiYmRjQGV4YW1wbGUubmV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN
0b3J5In0.PRBg-jXn4cJuj1gmYXFiGkZzRuzbXZ_sDxdE98ddW44ufsbWLKd3JJ1VZ
hF64pbTtfjy4VXFVBDaQpKjn5JzAw
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

27. KEVINDOCKX
MARVIN
DEMO TIME Time to dive into code
27

28. KEVINDOCKX
MARVIN
ADDITIONAL RESOURCES
Demo code on my Github
https://github.com/KevinDockx/
My Pluralsight Courses
https://app.pluralsight.com/profile/author/kevin-dockx
28

29. THANK YOU