Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Full stack security

2,402 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
  • Be the first to comment

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

×