Full stack security

1,247 views

Published on

OAuth/OpenID Connect and JWT connection frontend and backend

Author: Peter Varga, DPC Consulting
Event: HOUG Szakmai nap 2015, 2015.10.07

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,247
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
32
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Full stack security

  1. 1. Full Stack Security OAuth/OpenID Connect and JWT connecting frontend and backend DPC, Oct 2015 Peter.Varga @thevrg http://dpc.hu DPC Consulting Ltd
  2. 2. Agenda ● OAuth 2.0 ● OpenID Connect ● JSON Web Token (JWT) ● Demo ● Q&A
  3. 3. OAuth 2.0
  4. 4. OAuth 2.0 ● Open standard for authorization (RFC 6749) ● Provides a method for a third-party to access resources on behalf of a resource owner ● OAuth 2.0 token are also used to imply authentication ● OAuth 2.0 process consists of: 1. Obtaining an authorization grant 2. Obtaining an access token 3. Using the access token to make requests
  5. 5. Problems Addressed by OAuth 2.0 ● In traditional model, a third-party given access to a resource owner resources means: – Third-party must store the resource owner credentials – Third-party access is not limited in scope – Third-party access is not limited in time – The resource owner cannot revoke access to one third- party only; the only way to revoke access being a change in credentials ● OAuth2 presents an alternative solution addressing each of these issues
  6. 6. OAuth 2.0 Roles ● Client ● Resource Owner ● Authorization Server ● Resource Server
  7. 7. OAuth 2.0 Terminology ● Authorization Grant: – credentials representing the resource owner’s authorization – used by the client to obtain an access token ● Access Token: – credentials used to access protected resources – represents specific scopes and durations of access ● Refresh Token: – credentials used to obtain a new access token when current access token becomes invalid ● Scope: – determines the specific resources that can be accessed and the duration of the grant
  8. 8. OAuth 2.0 Clients ● Confidential: can protect their credentials – web applications ● Public: risk to expose their credentials – mobile phone apps – desktop clients – web-browsers ● Before OAuth2 process can take place, the client must register to the authorization server
  9. 9. Obtaining Access Token ● There are different ways to obtain an access token: – Authorization Code – Implicit – Resource Owner Password Credentials – Client Credentials – Extension Mechanism; e.g. SAML2 Token Insertion ● All communication must be performed through a secure channel
  10. 10. Authorization Code Flow
  11. 11. Authorization Code Flow (1-3) 1-2: Authorization Request https://oauthprovider.example.com/oauth/authorize? response_type=code&client_id= CLIENT_ID&redirect_uri= CALLBACK_URL&scope=rea d ● response_type= code ● client_id=CLIENT_ID ● redirect_uri=CALLBACK_URL ● scope=read 3: User authorizes request ● User authenticates if not authenticated yet
  12. 12. Authorization Code Flow (4-7) 4-5: Browser is redirected to Client’s CALLBACK_URL https://sample.oauthclient.com/callback?code= AUTHORIZATION_CODE ● code=AUTHORIZATION_CODE 6: Client requests Access Token POST https://oauthprovider.example.com/oauth/token Content-Type: application/x-www-form-urlencoded client_id=CLIENT_ID&client_secret= CLIENT_SECRET&grant_type=authorization_c ode&code=AUTHORIZATION_CODE &redirect_uri= CALLBACK_URL 7: Client receives Access Token {"access_token":" ACCESS_TOKEN","token_type":"bearer","expires_in":3872," refresh_token":" REFRESH_TOKEN","scope":"read","uid":,"info":{"name":"Peter Varga","email":"peter.varga@dpc.hu"}}
  13. 13. Implicit Flow
  14. 14. Implicit Flow (1-3) 1-2: Authorization Request https://oauthprovider.example.com/oauth/authorize? response_type=token&client_id= CLIENT_ID&redirect_uri= CALLBACK_URL&scope=re ad ● response_type= token ● client_id=CLIENT_ID ● redirect_uri=CALLBACK_URL ● scope=read 3: User authorizes request ● User authenticates if not authenticated yet
  15. 15. Implicit Flow (4-6) 4: Browser is redirected to Client’s CALLBACK_URL https://sample.oauthclient.com/callback #token=ACCESS_TOKEN ● #token=ACCESS_TOKEN 5: Client loads javascript which will extract token from hash ● The web server does not get access token directly 6: Script extracts Access Token from URL’s hash ● Now the script can share it with the client
  16. 16. Access Token ● The access token is a “bearer token”; anyone presenting it can obtain access: – The access token is sent through TLS/SSL from the authorization server to the client – The access token usually has a short life span and is renewed through refresh tokens ● A client can query the resource server endpoints to access resources/information
  17. 17. Accessing Resources ● Once in possession of an access token, the client presents the token to the resource server ● The resource server validates the token, its scope and its expiry date ● The validation generally requires interaction or coordination with the authorization server GET /protected/resource HTTP/1.1 Host: resource.example.com Authorization: Bearer ACCESS_TOKEN
  18. 18. Access Token Information ● The specification does not include the communication between the resource server and the authorization server ● There are proprietary mechanisms/implementations – The authorization server has an endpoint which can be used to get info about the presented access token GET /openam/oauth2/tokeninfo HTTP/1.1 Host: login.example.com Authorization: Bearer ACCESS_TOKEN
  19. 19. Bearer Token Recommendations ● Safeguard bearer tokens ● Validate TLS certificate chains ● Always use TLS (https) ● Don’t store bearer tokens in cookies ● Issue short-lived bearer tokens ● Issue scoped bearer tokens ● Don’t pass bearer tokens in URLs
  20. 20. OpenID Connect
  21. 21. OAuth 2.0 is NOT an Authentication Protocol
  22. 22. OpenID Connect ● OpenID connect = Identity, Authentication + OAuth2 ● OAuth 2.0 is an authorization protocol; when a client receives an access token it does not know the identity of the user ● OpenID Connect leverages the OAuth 2.0 handshake to provide Identity assertion through an ID token ● With OAuth 2.0 the client requests an access token; with OpenID Connect the client requests an access token and an ID token
  23. 23. OpenID Connect Flow
  24. 24. OpenID Connect Flow (1-3) 1-2: Authorization Request https://oauthprovider.example.com/oauth/authorize? response_type=code&client_id= CLIENT_ID&redirect_uri= CALLBACK_URL&scope=ope nid%20profile ● response_type= code ● client_id=CLIENT_ID ● redirect_uri=CALLBACK_URL ● scope=openid%20profile 3: User authorizes request ● User authenticates if not authenticated yet
  25. 25. OpenID Connect Flow (4-7) 4-5: Browser is redirected to Client’s CALLBACK_URL https://sample.oauthclient.com/callback?code= AUTHORIZATION_CODE ● code=AUTHORIZATION_CODE 6: Client requests Access Token POST https://www.googleapis.com/oauth2/v3/token Content-Type: application/x-www-form-urlencoded client_id=CLIENT_ID&client_secret= CLIENT_SECRET&grant_type=authorization_c ode&code=AUTHORIZATION_CODE &redirect_uri= CALLBACK_URL 7: Client receives Access Token {"access_token": "ya29.JgEXH5-koEv0wnizPyikm8qdpRG", "token_type": "Bearer","expires_in": 3597," id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6Ijc0ZWIyNDY1MGE0NzViNDkz. ZGQzZjFiMjU2MmM5MTZmOTA1MzIyOTAifQ. eyJpc3MiOiJhY2NvdW50cy5nb29nbGUuY29tIiwic3Vi"}
  26. 26. OpenID Connect ID Token ● Signed claim about user identity ● In Standard JSON Web Token (JWT) format ● Client must validate it: – Signature – Audience – Expiry – Nonce
  27. 27. JSON Web Token
  28. 28. JSON Web Token ● Compact, URL-safe means of representing claims to be transferred between two parties ● IETF Standard – https://tools.ietf.org/html/draft-ietf-oauth-json-web-token- 32 – http://jwt.io/ ● Simple Structure: – Header – Payload – Signature
  29. 29. JSON Web Token (JWT) Structure
  30. 30. User Information Endpoint ● OpenID Connect specifies it ● Retrieves the user info about the current session represented by the access token GET /openam/oauth2/userinfo HTTP/1.1 Host: login.example.com Authorization: Bearer ACCESS_TOKEN HTTP/1.1 200 OK Content-Type: application/json { "sub": "248289761001", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "email": "janedoe@example.com" }
  31. 31. Demo
  32. 32. Starting Implicit Flow with OpenID Connect
  33. 33. Processing Tokens Passed by the Authorization Server
  34. 34. Summary ● OAuth 2.0 ● OpenID Connect ● JSON Web Token (JWT) ● Demo ● Q&A
  35. 35. Q & A

×