Creating a Sign On with Open id connect
•Download as PPTX, PDF•
2 likes•1,452 views
The document discusses OpenID Connect, which is a standard for identity authentication built on OAuth 2.0. It describes the basic steps in OpenID Connect including the client requesting authentication, the authorization server authenticating the user and obtaining consent, returning an authorization code to the client, the client exchanging the code for an ID token and access token, and validating the ID token. It also addresses challenges with maintaining session state across a distributed architecture and strategies for addressing those challenges like embedding an iframe to check login status with the authorization server.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Creating a Sign On with Open id connect
Similar to Creating a Sign On with Open id connect (20)
Recently uploaded
Recently uploaded (20)
Creating a Sign On with Open id connect
- 1. Create a Sign On with Open ID Connect Derek Binkley @DerekB_WI
- 2. ★Lead Developer at National Conference of Bar Examiners ★PHP and Java Developer ★MySQL DBA ★Father of Three ★Home Pizza Chef ★@DerekB_WI
- 3. Questions • Yes! Please ask them. • During or at the end.
- 4. Why? OpenID Connect is a new standard Not a lot of documentation Built upon Oauth 2.0 which is widespread Sign On across disconnected services
- 5. What is a sign on? • Authentication (who are you?) • Authorization (what can you do?)
- 6. What is OpenID Connect? A Simple Identity layer on top of OAuth 2.0 Verify Identity User basic info REST-like Many client types
- 7. What is OAuth 2? • A method of allowing authorized access to web resources without the need for usernames and passwords. • More in Ben Ramsey's May 2016 PHP Architect article.
- 8. PHP Libraries • Bshaffer’s oauth2-server-php library
- 11. Session State/Authentication • Login maintained by connection between browser and Identity Provider
- 12. OpenID Steps 1. Client prepares an Authentication Request containing the desired request parameters. 2. Client sends the request to the Authorization Server. 3. Authorization Server Authenticates the End-User. 4. Authorization Server obtains End-User Consent/Authorization. 5. Authorization Server sends the End-User back to the Client with an Authorization Code. 6. Client requests a response using the Authorization Code at the Token Endpoint. 7. Client receives a response that contains an ID Token and Access Token in the response body. 8. Client validates the ID token and retrieves the End-User's Subject Identifier.
- 13. Setting up Your Auth Server
- 14. 1. Client prepares an Authentication Request containing the desired request parameters. • Client id • Client secret • Response Type • Scope • State
- 15. client_id/client_secret • Specific to your application • Sets Up Return URL
- 16. Response_type • Code • Id_token • Id_token token • Code id_token • Code token • Code id_token token
- 17. State • Unique string saved by your app • Prevents a forged return call from Identity Provider.
- 18. 2. Client sends the request to the Authorization Server. • Forward user to Auth Server URL • Have user post form to Auth Server
- 19. 3. Authorization Server Authenticates the End-User. • Implementation entirely up to you. • What? Isn’t this specification about authentication?
- 20. Authentication Methods • Something you know • Something you are • Something you have
- 21. 4. Authorization Server obtains End-User Consent/Authorization. • My app would like to access … Allow? • Optional if you are in control of all parts of the chain.
- 22. 5. Authorization Server sends the End-User back to the Client with an Authorization Code. • Forward to client URL • Either receive error or code. • Trade code for token.
- 23. Auth Server Code
- 25. 6. Client requests a response using the Authorization Code at the Token Endpoint. • Your PHP app sends an http request back to the Identity Provider (OpenID server). • Trades one time use code for token.
- 26. Client Code
- 27. 7. Client receives a response that contains an ID Token and Access Token in the response body. • Response back with ID token and access token • ID Token can be decrypted to ensure integrity and details of session
- 28. Server Code
- 29. Client Code
- 30. 8. Client validates the ID token and retrieves the End-User's Subject Identifier.
- 31. 8. Client validates the ID token and retrieves the End-User's Subject Identifier.
- 32. Taking it further with session handling • Sessions between App and Identity Provider don’t stay in sync. • No way for App to check.
- 34. Logout Problem • User logs out of Identity Provider then logins in as another user then returns to App. • App still has access token for first login. • App won’t know immediately that token has expired so could reveal one user’s data to another.
- 35. Embed an Iframe with Auth Server Connection • Send message to iframe to get user’s login status. • Handle response checking for ‘unchanged’
- 37. Content Security Policy in Apache Config • Header set Content-Security-Policy "default- src * 'unsafe-inline' 'unsafe-eval'; frame- ancestors 'self' *.example.com"
- 38. Thanks • Feedback at Meetup or Joind.in • https://joind.in/event/2016-madison-php-meetings
- 39. Resources • https://www.phparch.com/2016/05/may-2016-full-speed-ahead/ • http://openid.net/specs/openid-connect-core-1_0.html • http://openid.net/specs/openid-connect-session-1_0.html • http://bshaffer.github.io/oauth2-server-php-docs/cookbook/ • https://www.jwtinspector.io/
Editor's Notes
- Authentication – Username/Password, Login token, two factor Authorization – Once you know who the user is what are they allowed to do?
- OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.
- Mention access keys plus different grant types.
- For this talk we will be working with the Oauth 2.0 Server from Brent from Google.
- Straightforward to maintain login and session state. Each MVC app would have own login scheme.
- Micro services Node, Ruby, PHP Mobile Apps Where does the authentication go? Using a traditional LDAP/Active Directory it would go in each app. This violates DRY.
- Think about this for a minute. The applications still need to know who you are. How can we trust the web browser to tell us? Cookies are modifiable so on their own wouldn’t work. Two sessions can get out of sync, user logs out and another user logs in.
- Eight steps, let’s go through each step in detail.
- Explain each setup here but more detail to come.
- Basically like your apps username and password for the IDP.
- Code will use the authorization code flow
- Not as simple as it sounds. Browser has to submit. Server must accept get and post.
- Yes and No. It doesn’t get into the details of how to determine a user because that can change based on context. After user proves who they are how do you verify across servers?
- One or more of these can be used to identify a user. How to do this is a whole nother talk.
- Allow such and such app to access my Facebook profile
- TODO: insert picture of browser getting sent back to PHP app. Remember the client is the PHP app.
- Easy with library but details are obfuscated.
- Step through this Log statements added to help you see what is going on.
- At this point your PHP application finally has an identifier for who is logged in.
- Step through this
- Library handles it for you.
- Step through this
- iss REQUIRED. Issuer Identifier for the Issuer of the response. The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components. sub REQUIRED. Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST NOT exceed 255 ASCII characters in length. The sub value is a case sensitive string. aud REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case sensitive string. exp REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing. The processing of this parameter requires that the current date/time MUST be before the expiration date/time listed in the value. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular. iat REQUIRED. Time at which the JWT was issued. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. auth_time Time when the End-User authentication occurred. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. When a max_age request is made or when auth_time is requested as an Essential Claim, then this Claim is REQUIRED; otherwise, its inclusion is OPTIONAL. (The auth_time Claim semantically corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] auth_time response parameter.) nonce String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. If present in the ID Token, Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request. If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request. Authorization Servers SHOULD perform no other processing on nonce values used. The nonce value is a case sensitive string. acr OPTIONAL. Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied. The value "0" indicates the End-User authentication did not meet the requirements of ISO/IEC 29115 [ISO29115] level 1. Authentication using a long-lived browser cookie, for instance, is one example where the use of "level 0" is appropriate. Authentications with level 0 SHOULD NOT be used to authorize access to any resource of any monetary value. (This corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] nist_auth_level 0.) An absolute URI or an RFC 6711 [RFC6711] registered name SHOULD be used as the acr value; registered names MUST NOT be used with a different meaning than that which is registered. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The acr value is a case sensitive string.
- Let’s revisit Session is between laptop and IDP