This is a quick overview of the OAuth RFC 6749 and will cover some salient features mentioned there.
Implicit workflow is described as follows:
The client is issued an access token directly instead of the authorization code. This is done on the basis of resource owner authorization The client is issued an access token. Client is not verified. The access token is sent back in the uri fragment. Unauthorized parties could gain access to it. In some cases client can be verified with the redirect uri. Access tokens are issued with the minimal scope. Phishing attacks are possible where the access token can be switched with the another token previously issued to the attacker. Due to such security considerations, when authorization code grant is available, implicit might not be provisioned.
Other security scenarios include the following:
1) A malicious client can impersonate another client and obtain access to protected resources. This can be avoided with the registration of redirect uri and receiving authorization responses. The authentication server must authenticate the client whenever possible.
2) Access tokens must be kept confidential in transit and storage. TLS can be used for transit and database could be encrypted.
3) Authorization servers may issue refresh tokens to both web application and native application clients. Refresh tokens must be issued only to the client who was previously issued the token. The authorization server could also use refresh token rotation where the clients who used the previous token can be identifed.
4) Authorization codes must be short lived since it is used for the exchange of a token.
5) The redirect_uri parameter can be manipulated.
Implicit workflow is described as follows:
The client is issued an access token directly instead of the authorization code. This is done on the basis of resource owner authorization The client is issued an access token. Client is not verified. The access token is sent back in the uri fragment. Unauthorized parties could gain access to it. In some cases client can be verified with the redirect uri. Access tokens are issued with the minimal scope. Phishing attacks are possible where the access token can be switched with the another token previously issued to the attacker. Due to such security considerations, when authorization code grant is available, implicit might not be provisioned.
Other security scenarios include the following:
1) A malicious client can impersonate another client and obtain access to protected resources. This can be avoided with the registration of redirect uri and receiving authorization responses. The authentication server must authenticate the client whenever possible.
2) Access tokens must be kept confidential in transit and storage. TLS can be used for transit and database could be encrypted.
3) Authorization servers may issue refresh tokens to both web application and native application clients. Refresh tokens must be issued only to the client who was previously issued the token. The authorization server could also use refresh token rotation where the clients who used the previous token can be identifed.
4) Authorization codes must be short lived since it is used for the exchange of a token.
5) The redirect_uri parameter can be manipulated.
No comments:
Post a Comment