Full stack security
- 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. Agenda ● OAuth 2.0 ● OpenID Connect ● JSON Web Token (JWT) ● Demo ● Q&A
- 3. OAuth 2.0
- 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. 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. OAuth 2.0 Roles ● Client ● Resource Owner ● Authorization Server ● Resource Server
- 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. 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. 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
- 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. 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":"[email protected]"}}
- 13. Implicit Flow
- 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. 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. 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. 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. 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. 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. OpenID Connect
- 21. OAuth 2.0 is NOT an Authentication Protocol
- 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
- 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. 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. 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. JSON Web Token
- 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. JSON Web Token (JWT) Structure
- 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": "[email protected]" }
- 31. Demo
- 32. Starting Implicit Flow with OpenID Connect
- 33. Processing Tokens Passed by the Authorization Server
- 34. Summary ● OAuth 2.0 ● OpenID Connect ● JSON Web Token (JWT) ● Demo ● Q&A
- 35. Q & A