This post I'm making so that I read up on what the spec says. Its easy to get confused in the labyrinth of terms and use cases so I will focus on select cases.
Implicit client credential grant
The RFC for OAuth calls implicit grant a simplified authorization flow because it issues a client token directly instead of an intermediate authorization code. The client is issued an access token directly because the resource owner is authenticated. When issuing an access token to the client, the client Id is not verfiied. This is different from what I mentioned in the previous post. The redirect_uri in the token grant is intended to deliver the token to the client. The token may be exposed to the resource owner or other applications with access to the resource owner's user-agent. The access token security says that tokens can be generated or guessed by unauthorized parties and that its delivery should be over the TLS. Further the scope of the token should be as minimal as possible. The authorization server should though not a must verify the client identity.
there is no provisioning to verify that the token presented by a client was indeed issued by the server.
The RFC calls out a section for the native applications.
Native applications are clients installed and executed on the device used by the resource owner. The authorization endpoint requires interaction between the client and the resource owners' user agent. Native applications can invoke an external user-agent or embed a user-agent within the application.
If an external user agent is involved, the application can capture the response from the authorization server using a redirection URI and a callback for the JSON response from the server or manually copy and paste of the credentials or running a local web server or installing a user-agent extension to identify a server hosted resource which in turn makes the response available to the native application
If the user agent is embeded, the native application obtains the response with the redirect_uri and the token by directly communicating with the embedded user-agent such as resource load or cookies.
An external user-agent reassures the user to enter his password since this is going to the same site where he or she has been doing so and may even rely on features that come with the site. It also offloads the session persistence and sign-on/sign-off from multiple devices for the user. Thi shsould be preferred.
An embedded user-agent removes the need to switch context or open new windows and the client can directly communicate with the user agent over the local device. But it leads to security vulnerabilities such as phising attacks.
When choosing between an implicit grant type and the authorization code grant type, native applications should request the code without the client credentials beacuse the native application cannot keep the client credentials confidential. This is why client id and client secret should not be hardcoded in the application and made avialable in the binary of the installation.
In the implicit grant type, there is no refresh token so on token expiry the authorization process is repated.
Implicit client credential grant
The RFC for OAuth calls implicit grant a simplified authorization flow because it issues a client token directly instead of an intermediate authorization code. The client is issued an access token directly because the resource owner is authenticated. When issuing an access token to the client, the client Id is not verfiied. This is different from what I mentioned in the previous post. The redirect_uri in the token grant is intended to deliver the token to the client. The token may be exposed to the resource owner or other applications with access to the resource owner's user-agent. The access token security says that tokens can be generated or guessed by unauthorized parties and that its delivery should be over the TLS. Further the scope of the token should be as minimal as possible. The authorization server should though not a must verify the client identity.
there is no provisioning to verify that the token presented by a client was indeed issued by the server.
The RFC calls out a section for the native applications.
Native applications are clients installed and executed on the device used by the resource owner. The authorization endpoint requires interaction between the client and the resource owners' user agent. Native applications can invoke an external user-agent or embed a user-agent within the application.
If an external user agent is involved, the application can capture the response from the authorization server using a redirection URI and a callback for the JSON response from the server or manually copy and paste of the credentials or running a local web server or installing a user-agent extension to identify a server hosted resource which in turn makes the response available to the native application
If the user agent is embeded, the native application obtains the response with the redirect_uri and the token by directly communicating with the embedded user-agent such as resource load or cookies.
An external user-agent reassures the user to enter his password since this is going to the same site where he or she has been doing so and may even rely on features that come with the site. It also offloads the session persistence and sign-on/sign-off from multiple devices for the user. Thi shsould be preferred.
An embedded user-agent removes the need to switch context or open new windows and the client can directly communicate with the user agent over the local device. But it leads to security vulnerabilities such as phising attacks.
When choosing between an implicit grant type and the authorization code grant type, native applications should request the code without the client credentials beacuse the native application cannot keep the client credentials confidential. This is why client id and client secret should not be hardcoded in the application and made avialable in the binary of the installation.
In the implicit grant type, there is no refresh token so on token expiry the authorization process is repated.
No comments:
Post a Comment