OAuth2 Presentaion
- 2. What is OAuth ? Oauth is the industry-standard protocol for authorization. Oauth is an specification/Protocol that enables applications to obtain limited access to user accounts. How it works ? It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account. Who will use? It provides authorization flows for web and desktop applications, and mobile devices.
- 3. • Authorization Server e.g. Face book, Google, Git hub etc. https://en.wikipedia.org/wiki/List_of_OAuth_providers • Resource Server Limited User information •Client (Third party App) Application which requires authentication and authorization • Resource Owner User who has account in Authorization server
- 4. Redbus.in Application using Authorization with Google/Facebook authorization servers
- 6. Access Tokens (Short lived) With this token, we access the authorized resource Refresh Tokens (Long lived) When ever access token expires, we use refresh token to get the new access token.
- 7. An authorization code is an intermediate token used in the server- side app flow. An authorization code is returned to the client after the authorization step, and then the client exchanges it for an access token. Scope is a way to limit an app’s access to a user’s data. Rather than granting complete access to a user’s account, it is often useful to give apps a way to request a more limited scope of what they are allowed to do on behalf of a user. e.g. read, write, trust or email etc..
- 8. Authorization End Point https://authorization-server.com/authorize Returns the response with authorization code and state And also gives the screen to user saying Approve /Deny of sharingyour public data with Client Application. Token End point https://authorization-server.com/token { "access_token": "381e44d1-3b79-4b2b-826e-b414f06989b8", "token_type": "bearer", "refresh_token": "3bb99a06-5d9b-4329-91df-42ad0b952853", "expires_in": 43199, "scope": "read write“ }
- 9. The OAuth 2.0 specification lists four different types of authorization grants. Each type has different security characteristics.
- 10. • Authorization Code Grants • Implicit Grants • Password Grants • Client Credentials Grants
- 12. Implicit
- 13. Resource Owner Password Credentials
- 19. • Decouples resource owner credentials over head from Resources. • Client Application doesn’t have to maintain authentication. • Resource Owners (Users) don’t need to have multiple logins.
Editor's Notes
- #4: Authorization Server – Facebook or Google or Github etc.. Resource Server – User Accounts Client – Redbus.in Resource Owner – Users who has account in Facebook/Google/Github and wants to log in Redbus.in application
- #5: Google Oauth https://accounts.google.com/signin/oauth/oauthchooseaccount?client_id=231171689615-idianhahjhk2s9rdlr1hrd9e2a09b3cj.apps.googleusercontent.com&as=-30c12e6fde8576ce&destination=https%3A%2F%2Fwww.redbus.in&approval_state=!ChRZb2hNenR2NmNUQmlSTk1hWUk4LRIfUTZNWWJUTzVhSEVhVU9xWmlfQjdtUjlrRUpzS0NoWQ%E2%88%99ACThZt4AAAAAWkceu1dXTeKbHkXCN-vEyg0EN4omYuT6&xsrfsig=AHgIfE-8qupE90XAlxCML8F4cCK8SD0-2w&flowName=GeneralOAuthFlow Facebook O Auth Link https://www.facebook.com/dialog/oauth?app_id=377581119008028&channel_url=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter%2Fr%2FlY4eZXm_YWu.js%3Fversion%3D42%23cb%3Df412aaa45d5424%26domain%3Dwww.redbus.in%26origin%3Dhttps%253A%252F%252Fwww.redbus.in%252Ff3f1486533c3e04%26relation%3Dopener&client_id=377581119008028&display=popup&domain=www.redbus.in&e2e=%7B%7D&locale=en_US&origin=1&redirect_uri=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter%2Fr%2FlY4eZXm_YWu.js%3Fversion%3D42%23cb%3Df3d20b7232ee724%26domain%3Dwww.redbus.in%26origin%3Dhttps%253A%252F%252Fwww.redbus.in%252Ff3f1486533c3e04%26relation%3Dopener%26frame%3Df4fa8c18f35e9c&response_type=token%2Csigned_request&scope=email&sdk=joey DigitalOcean OAuthLink https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read https://developer.github.com/apps/building-oauth-apps/authorization-options-for-oauth-apps/#non-web-application-flow
- #8: More about Scope… Some apps only use OAuth in order to identify the user, so they only need access to a user ID and basic profile information. Other apps may need to know more sensitive information such as the user’s birthday, or they may need the ability to post content on behalf of the user, or modify profile data. Users will be more willing to authorize an application if they know exactly what the application can and cannot do with their account. Scope is a way to control access and help the user identify the permissions they are granting to the application.
- #9: If you give Bearer ( Default on most implementation), an access_token is generated and sent back to you. Bearer can be simply understood as "give access to the bearer of this token." One valid token and no question asked. On the other hand if you choose Mac and sign_type(default hmac-sha-1 on most implementation), the access token is generated and kept as secret in Key Manager as a attribute, and an encrypted secret is sent back as access_token JWT – JSON Web Token. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
- #12: Authorization Code Grant When it should be used? It should be used as soon as the client is a web server. It allows you to obtain a long-lived access token since it can be renewed with a refresh token (if the authorization server enables it). Example: Resource Owner: you Resource Server: a Google server Client: any website Authorization Server: a Google server Scenario: A website wants to obtain information about your Google profile. You are redirected by the client (the website) to the authorization server (Google). If you authorize access, the authorization server sends an authorization code to the client (the website) in the callback response. Then, this code is exchanged against an access token between the client and the authorization server. The website is now able to use this access token to query the resource server (Google again) and retrieve your profile data. You never see the access token, it will be stored by the website (in session for example). Google also sends other information with the access token, such as the token lifetime and eventually a refresh token. This is the ideal scenario and the safer one because the access token is not passed on the client side (web browser in our example).
- #13: t is typically used when the client is running in a browser using a scripting language such as Javascript. This grant type does not allow the issuance of a refresh token. Example: Resource Owner: you Resource Server: a Facebook server Client: a website using AngularJS for example Authorization Server: a Facebook server Scenario: The client (AngularJS) wants to obtain information about your Facebook profile. You are redirected by the browser to the authorization server (Facebook). If you authorize access, the authorization server redirects you to the website with the access token in the URI fragment (not sent to the web server). Example of callback: http://example.com/oauthcallback#access_token=MzJmNDc3M2VjMmQzN. This access token can now be retrieved and used by the client (AngularJS) to query the resource server (Facebook). Example of query: https://graph.facebook.com/me?access_token=MzJmNDc3M2VjMmQzN. Access-Control-Allow-Origin Maybe you wonder how the client can make a call to the Facebook API with Javascript without being blocked because of the Same Origin Policy? his cross-domain request is possible because Facebook authorizes it thanks to a header called Access-Control-Allow-Origin present in the response. Java Script Applications Mobile Apps
- #14: POST https://api.authorization-server.com/token grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID A common use for this grant type is to enable password logins for your service’s own apps. The response will include an access token in the same format as the other grant types When it should be used? With this type of authorization, the credentials (and thus the password) are sent to the client and then to the authorization server. It is therefore imperative that there is absolute trust between these two entities. It is mainly used when the client has been developed by the same authority as the authorization server. For example, we could imagine a website named example.com seeking access to protected resources of its own subdomain api.example.com. The user would not be surprised to type his login/password on the site example.com since his account was created on it. Example: Resource Owner: you having an account on acme.com website of the Acme company Resource Server: Acme company exposing its API at api.acme.com Client: acme.com website from Acme company Authorization Server: an Acme server Scenario: Acme company, doing things well, thought to make available a RESTful API to third-party applications. This company thinks it would be convenient to use its own API to avoid reinventing the wheel. Company needs an access token to call the methods of its own API. For this, company asks you to enter your login credentials via a standard HTML form as you normally would. The server-side application (website acme.com) will exchange your credentials against an access token from the authorization server (if your credentials are valid, of course). This application can now use the access token to query its own resource server (api.acme.com).
- #15: The Client Credentials grant is used when applications request an access token to access their own resources, not on behalf of a user. http://www.mysmartprice.com/ When it should be used? This type of authorization is used when the client is himself the resource owner. There is no authorization to obtain from the end-user. Example: Resource Owner: any website Resource Server: Google Cloud Storage Client: the resource owner Authorization Server: a Google server Scenario: A website stores its files of any kind on Google Cloud Storage. The website must go through the Google API to retrieve or modify files and must authenticate with the authorization server. Once authenticated, the website obtains an access token that can now be used for querying the resource server (Google Cloud Storage). Here, the end-user does not have to give its authorization for accessing the resource server.
- #17: https://github.com/settings/applications/new
- #19: Resource http://localhost:8000/resource/ords Authorization http://localhost:9000/service/oauth/authorize http://localhost:9000/service/oauth/token