- Authentication is the process of validating whether a person (or system) is actually who they say they are.
- Authorization is the process of determining what actions you are allowed to perform once you have been authenticated.
- Allowing a user to log into an application with another account. For example, Pinterest allowing users to log in with their Twitter accounts. This is known as federated identity.
- Allowing one service to access resources on another service on behalf of the user. For example, Adobe accessing your Facebook photos on your behalf. This is known as delegated authority.
Federated identity is an important concept in identity management. It refers to the concept that allows one service provider to allow authentication of a user using their identity with another service provider.
Note Strictly speaking, the OAuth 2.0 protocol is actually an authorization protocol and not an authentication protocol. Because of this, OAuth 2.0 alone cannot provide federated identity. However, when used in a certain way, and in conjunction with other protocols, OAuth 2.0 can provide federated authentication, which is a key component to federated identity systems.
Delegated authority is another important concept in the identity space. It refers to the ability for a service or application to gain access to a user’s resources on their behalf.
- Security Consideration
TIP
The authorization code grant flow is the most secure
Because of the presence of a backend server for clients that use the authorization code grant flow, these clients can make secure communications to the service provider that aren’t visible to users and attackers, making this the most secure, and preferred, grant flow to use.
TIP
Refresh tokens reduce the number of times your users have to re-authenticate
Making effective use of refresh tokens can minimize the opportunities attackers have to steal user credentials, as well as provide a better user experience by extending their sessions with your client without intervention.
Use native browsers instead of embedded browsers
The use of native external browsers over embedded browsers pertains particularly to native applications (that is, desktop applications and mobile applications). Often, when implementing a native application, you can choose to initiate the authorization flow in either the native system browser or an embedded browser within your application.
For example, if you are developing an iPhone application and want to start the authorization flow for a user, you can choose to do this through the native iPhone Safari browser. Or, you can choose to use an embedded browser provided by the SDK directly in your application. Thischoice has many important, but subtle, consequences, relating to both security and usability.
Initially, you may want to use an embedded browser for your application. This will provide a more seamless user experience since users can stay in your application without having to bring the native system browser to the front momentarily for authentication and authorization. However, there are some very good reasons to use the native system browser.
The most important reason for using the native system browser is that you can leverage the system chrome to display security information related to the target service provider’s authorization endpoint. For instance, native browsers will often display warnings for sites with invalid or expired certificates, whereas embedded browsers often do not. This makes phishing attacks easier. (Refer to Phishing in the Common attacks section later in this chapter for more information.)
Native system browsers use a different cookie jar than embedded browsers. So, if a user already has an active session in the system browser, they can piggyback on this. Whereas, in an embedded browser, since sessions aren’t shared with the native browser, they will likely have to start a new session.
Additionally, native system browsers may have plugins available to it, like password managers, which would not be available to embedded browsers.
| Native external system browser | Embedded browser |
| Pros: Makes use of system chrome which can display important security information related to the currently loaded page.Uses the system cookie store, so it is able to take advantage of already-active sessions.Plugins are available (for example, password managers). | Pros: Provides a more seamless user experience since the user can stay within the context of the client application without having to switch contexts to a system browser to log in. |
| Cons: A less than ideal user experience since it requires the system browser to be brought to the forefront for the user to authenticate and authorize. | Cons: Does not often display the security information related to the currently loaded page. Makes phishing attacks easy since it is hard for users to confirm the validity of the page they are looking at.Uses a different cookie store from the system browser. Users will most likely have to log in since they won’t have a valid session with this browser.No plugins available. |
Do not use third-party scripts in the redirection endpoint
When constructing your redirection endpoint, make sure that you do not include any third-party or externally loaded scripts. These scripts have access to your redirection URI and the credentials it contains. It is possible that these scripts can be compromised and, if loaded externally, could leak your access tokens or authorization codes to attackers.
Rotate your client credentials
Just as you should for your own personal password, you should rotate your client credentials. This minimizes the attack vectors available to attackers since, if you rotate your credentials regularly, they will have a more limited time to utilize them if they are leaked.
A good practice would be to rotate these credentials with every release (or major release, depending on your security requirements and development cycle).
WHAT’S GOING ON?
Note that the first workflow is the typical authorization workflow that we are used to. However, in the second workflow, we can see that there is another party, namely, the attacker. In this scenario, the attacker sends a malicious authorization code or access token directly to the client application’s redirect URI. Since the client application can’t verify that the token is valid, it continues to use it to communicate with the service provider. As the token is attacker-owned, this may result in the attacker gaining access to the protected resources of the user.
This happens mainly because the client application has no way of verifying that the authorization code or access token that has been issued to it is the result of a valid request made by the application. To combat this, the client application must make use of the state param.
USE THE STATE PARAM TO COMBAT CSRF
In order for your client application to protect against CSRF, your client application must gain the ability to verify whether the authorization codes or access tokens issued to it are valid (that is, they are the result of a valid authorization request by the user from your client application). To do this, your client application must generate a session-specific, unguessable value that it can pass along with its authorization request. When an authorization code or access token is returned back to the redirect URI, your application can validate that value to ensure that it was indeed used as part of a valid authorization request initiated by the user, and not by some attacker.
NOTE
If a state param value is passed to a service provider, the OAuth 2.0 specification mandates that it be returned back to the client application untouched. This mechanism is designed specifically to mitigate such CSRF attacks, and should be used particularly for this reason.
피싱 If you use native external browsers in your application, your users will have an increased ability to verify the authenticity of the authorization endpoint that they are seeing.