Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Ladies Be Architects - Study Group III: OAuth 2.0 (Ep 1)
Similar a Ladies Be Architects - Study Group III: OAuth 2.0 (Ep 1) (20)
Más de gemziebeth
Más de gemziebeth (7)
Último
Último (20)
Ladies Be Architects - Study Group III: OAuth 2.0 (Ep 1)
- 1. STUDY GROUP 1I1: OAUTH 2.0 (PART 1) CHARLY PRINSLOO
- 2. charlyprinsloo charly.prinsloo Next Planned Cert: Mobile Designer My deadline for CTA: April 2018 I can help others with: • Data • Identity and Access Management Salesforcing since: 2005 I work for a: Partner App Architect: Yes System Architect: Yes Superbadges: 1 I Love: Solving problems Charly Prinsloo
- 3. FEBRUARY CHAMPIONS Susan Linck Platform App Builder Tami Lau Data Architecture & Management Designer Application Architect Charly Prinsloo Field Service Lightning Consultant
- 4. AGENDA W h e n ? W h y ? • Salesforce Flows • Setting up Oauth 2.0 in salesforce • How do I choose? • Know your flows • Components • The Roles • Tokens • Scopes & Consents • Flows & Grants • Where does it fit in? • Identity Standards & Protocol • What is Oauth 2.0? • Why Oauth 2.0? W h o ? W h a t ? Session 2
- 5. WHERE DOES OAUTH 2.0 FIT IN? IDENTITY MANAGEMENT CONCEPTS 34% ACCEPTING 3RD PARTY IDENTITY IN SALESFORCE 21% SALESFORCE AS AN IDENTITY PROVIDER 18% ACCESS MANAGEMENT BEST PRACTICES 12% SALESFORCE IDENTITY 8% COMMUNITY (PARTNER AND CUSTOMER), 7% IDENTITY AND ACCESS MANAGEMENT The Salesforce Certified Identity and Access Management Designer candidate has the experience, skills, knowledge, and ability to explain high-level concepts and flows of OAuth. Given a scenario, troubleshoot common points of failure that may be encountered in a single sign-on solution (SAML, OAuth, etc.). Given a scenario, determine the most appropriate flow type to recommend when implementing an OAuth solution where Salesforce is providing identity to a 3rd party (E.g. User Agent, Web Server, JWT, etc.) Describe the various implementation concepts of OAuth (E.g. scopes, secrets, tokens, refresh tokens, token expiration, token revocation, etc.) W h a t?
- 6. IDENTITY STANDARDS AND PROTOCOLS Hard to believe that you can keep your users’ identities secure when they don’t have to sign in to external websites or apps? How can so many companies’ products, even competing products, work together? The answer: industry standards and protocols for identity and access management. That might sound intimidating, but it doesn’t have to be. A standard is just a set of widely agreed- upon practices that industry members follow. A standard can include a protocol that specifies how systems exchange information. Here are the three protocols that Salesforce and other identity vendors follow to implement identity solutions. • SAML • OAuth 2.0 • OpenID Connect W h a t?
- 7. WHAT IS OAUTH 2.0? OAuth 2.0 is an open authorization protocol/framework that enables an application to obtain secure, limited access and data sharing to a HTTP service. Open Authorization OAuth 2.0 is a complete rewrite of OAuth 1.0 from the ground up, sharing only overall goals and general user experience. OAuth 2.0 is not backwards compatible with OAuth 1.0 or 1.1, and should be thought of as a completely new protocol. the function of specifying access rights to resource A set of rules governing the exchange or transmission of data between devices. Web, desktop, mobile Secure, limited Http service OAuth is not an API or a service OAuth 2.0 is not an authentication protocol. W h a t?
- 8. WHY OAUTH 2.0 • Before OAuth, sites would prompt you to enter your username and password directly into a form and they would login to your data (e.g. your Gmail account) as you. direct authentication pattern • Federated identity was created for single sign-on (SSO), and SAML 2.0 was launched in 2005, and it made sense. • Single Page Applications (SPAs), mobile phones, TVs, gaming consoles and IoT devices with AJAX (background HTTP calls) to APIs delegated authorization framework for REST/APIs W h a t?
- 9. OAUTH 2.0 COMPONENTS • Roles (the Actors) • Tokens • Scopes and Consent • Grants in Flows H o w ?
- 10. THE ROLES a.k.a token issuer (DMV or Passport Office) Authorization Server Resource Owner a.k.a the End User/Yourself Client a.k.a the application • An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user. • resource owner owns the data in the resource server. • Example, I’m the Resource Owner of my Facebook profile. • The server hosting the protected resources, including user accounts, • Capable of accepting and responding to protected resource requests using access tokens. • Example: Google hosting your profile and personal information. • API server a.k.a. the API server Resource Server API • The application that wants to access your data or the user's account, requesting access to a resource server • An application making protected resource requests on behalf of the resource owner and with its authorization. • The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices). AUTH • The main engine of Oauth • The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. This token will be used for the client to request the resource server. • This server can be the same as the authorization server (same physical server and same application), and it is often the case. H o w ?
- 11. TOKENS & ENDPOINTS • Access Token • Refresh Token • The two main endpoints are the authorize endpoint and the token endpoint. H o w ? AUTH authorize endpoint token endpoint Authorization Grant Refresh Token Access Token https://login.salesforce.c om/services/oauth2/auth orize https://login.salesforce.c om/services/oauth2/toke n
- 12. SCOPES AND CONSENT AUTH = = API& Scopes to Allow Scopes to Deny Total Scope available from RS H o w ?
- 13. GRANTS • Authorization Code Grant • Implicit Grant • Resource Owner Password Credentials Grant • Client Credentials Grant
- 14. 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). What is good about it? This is the ideal scenario and the safer one because the access token is not passed on the client side
- 15. IMPLICIT GRANT When it should be used? It 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. What is good about it? Not much… This type of authorization should only be used if no other type of authorization is available. It is the least secure because the access token is exposed on the client side.
- 16. RESOURCE OWNER PASSWORD CREDENTIALS GRANT When it should be used? It is mainly used when the client has been developed by the same authority as the authorization server. For example, 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.
- 17. CLIENT CREDENTIALS GRANT 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. What is good about it? The end-user does not have to give its authorization for accessing the resource server.
- 18. GRANTS AT A GLANCE Authorization Grant type Authorization Code The Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants Implicit Resource Owner Password Credentials Client Credentials Salesforce OAuth 2.0 Flows Web Server JWT Token SAML Bearer Assertion SAML Assertion User Agent UserName and Password Summary The gold standard, most commonly used -it is optimized for server-side aka 3 Legged Tokens are sent directly from the Authorization Server to the Client app, providing a high level of security. JSON Web Token (JWT) is a JSON- based security token encoding that enables identity and security information to be shared across security domains. A SAML assertion is an XML security token issued by an identity provider and consumed by a service provider. The service provider relies on its content to identify the assertion’s subject for security-related purposes. The SAML assertion flow is an alternative for orgs that are currently using SAML to access Salesforce and want to access the web services API the same way. You don’t have to create a connected app to use this assertion flow. All communication is happening through the browser The authorization server returns an access token. The access token is given to the user- agent to forward to the application It is mainly used when the client has been developed by the same authority as the authorization server. This type of authorization is used when the client is himself the resource owner. There is no authorization to obtain from the end-user. Refresh Token Provides a Refresh Token to get a new Access token No A refresh token is never issued in this flow. A refresh token is never issued in this flow. It typically does not support refresh tokens. A refresh token is never issued in this flow. A refresh token is never issued in this flow. Drawbacks • N/A, It’s the most secure flow because you can authenticate the client to redeem the authorization grant, and tokens are never passed through a user- agent. Only when SAML SSO is implemented You can use the SAML assertion flow only inside a single org. should only be used if no other type is available. the least secure the most vulnerable to security threats. Use this authentication flow only when necessary. No refresh token is issued. H o w ?
- 19. No SO HOW DO I CHOOSE THE RIGHT GRANT? Is the Client the Resource Owner? Is the Client a Web App executing on the server? Ye s No Ye s Username Password Flow (Client Credentials Grant) Web Server Flow (Authorization Code Grant) Is the Client absolutely trusted with user credentials? Ye s Username Password Flow (Resource Owner Password Credentials Grant) No Is the Client a native app or a SPA? Nativ e app Web Server Flow (Authorization Code Grant) SPA User-Agent Flow (Implicit Grant)
- 20. QUESTIONS?
- 21. RESOURCES • Read the Oauth specs • RFC 6749 - The OAuth 2.0 Authorization Framework • RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage • OAuth Site • https://developers.google.com/oauthplayground/ • Attend the next study group – Oauth 2.0 and Salesforce
- 22. THANK YOU. Join our Trailblazer Community group – don’t forget to fill out your personal profile! Post your exam successes into the group If you tweet, use #LadiesBeArchitects & tag @ArchLadies Run a study group for us Speak at one of our Inspire meet-ups Blog / talk about us
Notas del editor
- OAuth was created as response to the direct authentication pattern. This pattern was made famous by HTTP Basic Authentication, where the user is prompted for a username and password. Basic Authentication is still used as a primitive form of API authentication for server side applications: instead of sending a username and password to the server with each request, the user sends an API key ID and secret. Before OAuth, sites would prompt you to enter your username and password directly into a form and they would login to your data (e.g. your Gmail account) as you. To create a better system for the web, federated identity was created for single sign-on (SSO). In this scenario, an end user talks to their identity provider, and the identity provider generates a cryptographically signed token which it hands off to the application to authenticate the user. The application trusts the identity provider. As long as that trust relationship works with the signed assertion, you’re good to go. However, a lot has changed since then. Now we have modern web and native application development platforms. There’s Single Page Applications (SPAs) like Gmail/Google Inbox, Facebook, and Twitter. They have different behaviors than your traditional web application, because they make AJAX (background HTTP calls) to APIs. Mobile phones make API calls too, as do TVs, gaming consoles, and IoT devices. SAML SSO isn’t particularly good at any of this. Now, most developers have moved to REST and stateless APIs. REST is, in a nutshell, HTTP commands pushing JSON packets over the network. Developers build a lot of APIs.. Companies need to protect their REST APIs in a way that allows many devices to access them. In the old days, you’d enter your username/password directory and the app would login directly as you. This gave rise to the delegated authorization problem. “How can I allow an app to access my data without necessarily giving it my password?” This is OAuth.
- OAuth is built on the following central components:
- There are 4 main roles (or players or actors) in an OAuth transaction resource owner -- An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user. resource server -- The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. Client -- An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices). authorization server -- The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
- Tokens are random strings generated by the authorization server and are issued when the client requests them. There are 2 types of token: Access Token: this is the most important because it allows the user data from being accessed by a third-party application. This token is sent by the client as a parameter or as a header in the request to the resource server. It has a limited lifetime, which is defined by the authorization server. It must be kept confidential as soon as possible but we will see that this is not always possible, especially when the client is a web browser that sends requests to the resource server via Javascript. Think of them in hours and minutes, not days and month. You don’t need a confidential client to get an access token. You can get access tokens with public clients. They’re designed to optimize for internet scale problems. Because these tokens can be short lived and scale out, they can’t be revoked, you just have to wait for them to time out. Refresh Token: this token is issued with the access token but unlike the latter, it is not sent in each request from the client to the resource server. It merely serves to be sent to the authorization server for renewing the access token when it has expired. For security reasons, it is not always possible to obtain this token. We will see later in what circumstances. This is much longer-lived; days, months, years. This can be used to get new tokens. To get a refresh token, applications typically require confidential clients with authentication. Endpoints Tokens are retrieved from endpoints on the authorization server. The two main endpoints are the authorize endpoint and the token endpoint. They’re separated for different use cases. The authorize endpoint is where you go to get consent and authorization from the user. This returns an authorization grant that says the user has consented to it. Then the authorization is passed to the token endpoint. The token endpoint processes the grant and says “great, here’s your refresh token and your access token”. You can use the access token to get access to APIs. Once it expires, you’ll have to go back to the token endpoint with the refresh token to get a new access token.
- The scope is a parameter used to limit the rights of the access token. This is the authorization server that defines the list of the available scopes. The client must then send the scopes he wants to use for his application during the request to the authorization server. More the scope is reduced, the greater the chance that the resource owner authorizes access. The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. The value of the scope parameter is expressed as a list of space- delimited, case-sensitive strings. The strings are defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted. If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value or fail the request indicating an invalid scope. The authorization server SHOULD document its scope requirements and default value (if defined).
- An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. The OAuth2 specification defines four grant types depending on the location and the nature of the client involved in obtaining an access token -- authorization code, implicit, resource owner password credentials, and client credentials -- as well as an extensibility mechanism for defining additional types.
- 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).
- When it should be used? It 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.
- This grant is a great user experience for trusted first party clients both on the web and in native device applications. 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. When it should be used? 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).
- The simplest of all of the OAuth 2.0 grants, this grant is suitable for machine-to-machine authentication where a specific user’s permission to access data is not required. 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.
- OAuth defines four grant types: authorization code, implicit, resource owner password credentials, and client credentials. The Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [I-D.ietf-oauth-assertions] specification is an abstract extension to OAuth 2.0 that provides a general framework for the use of Assertions (a.k.a. Security Tokens) as client credentials and/or authorization grants with OAuth 2.0.
- The first decision point is about whether the party that requires access to resources is a machine. In this case of machine to machine authorization, the Client is also the Resource Owner. No end-user authorization is needed in this case. An example is a cron job that uses an API to import information to a database. In this example the cron job is the Client and the Resource Owner since it holds the Client Id and Client Secret and uses them to get an Access Token from the Authorization Server. Client Credentials Grant. If the Client is a regular web app executing on a server then the Authorization Code Grant is the flow you should use. Using this the Client can retrieve an Access Token and, optionally, a Refresh Token. It's considered the safest choice since the Access Token is passed directly to the web server hosting the Client, without going through the user's web browser and risk exposure. Web Server Flow Authorization Code Grant. This decision point may result to suggesting the Resource Owner Password Credentials Grant. In this flow the end-user is asked to fill in credentials (username/password) typically using an interactive form. This information is sent to the backend and from there to Auth0. It is therefore imperative that the Client is absolutely trusted with this information. If the Client is a Single Page Application (meaning an application running in a browser using a scripting language such as Javascript) then the Implicit Grant should be used. In this case, instead of getting an authorization code that needs to be exchanged for an Access Token, the Client retrieves directly an Access Token. On the plus side, this is more efficient since it reduces the number of round trips required to get an Access Token. However, a security consideration is that the Access Token is exposed on the client side. Also, it should be noted that Implicit Grant does not return a Refresh Token because the browser cannot keep it private (read the SPAs and Refresh Tokens panel for a workaround).