The previous post on OAuth testing discussed the mapping of user and client for grant of token. Therefore testing discussed mostly on the setup of a user and client for the purpose of grant token. The token has a certain expiry time. There was some mention about scope and state. In this post, we discuss the revokes
When the authorization website grants access to a client from a user, the client can get a "bearer" token to access the protected resources. This token can be used by anyone for any of the APIs. The authorization server must implement TLS so that the passwords and bearer tokens can flow.
OAuth only mandates that the token are issued for less than an hour. However clients, user and the authorization website could establish trust relationship the first time the authorization occurs. This is outside the scope of OAuth and may be provided as a mere convenience to the user from having to sign on each time for the client.
If this relationship were to be persisted it would merely be a table mapping the client with the user on this server. The records could be added when the authorization completes and revoked when the user explictly wants to clean up the clients she has authorized. The authorization website identifies the user by the user id and the client by the client id. When the client requests the authorization again subsequently, the website may have the user signed on from a previous session and hence uses the same to generate a token for the client. Neither the user specifies password again, nor does the client change request anything different other than accepting the redirect uri response with the token it is expecting.
Care should be taken to ensure that retries by the user do not create duplicate rows in the table maintained by the authorization website. In addition to user explicit revokes, the website may grant additional session time than the usual token expiry time. This can be facilitated with the use of a timestamp.
Lastly the website may do periodic cleanups and archival of the trust relationships. The default case could be to not store the trust relationships and have the token expirty time force re-authentication.
When the authorization website grants access to a client from a user, the client can get a "bearer" token to access the protected resources. This token can be used by anyone for any of the APIs. The authorization server must implement TLS so that the passwords and bearer tokens can flow.
OAuth only mandates that the token are issued for less than an hour. However clients, user and the authorization website could establish trust relationship the first time the authorization occurs. This is outside the scope of OAuth and may be provided as a mere convenience to the user from having to sign on each time for the client.
If this relationship were to be persisted it would merely be a table mapping the client with the user on this server. The records could be added when the authorization completes and revoked when the user explictly wants to clean up the clients she has authorized. The authorization website identifies the user by the user id and the client by the client id. When the client requests the authorization again subsequently, the website may have the user signed on from a previous session and hence uses the same to generate a token for the client. Neither the user specifies password again, nor does the client change request anything different other than accepting the redirect uri response with the token it is expecting.
Care should be taken to ensure that retries by the user do not create duplicate rows in the table maintained by the authorization website. In addition to user explicit revokes, the website may grant additional session time than the usual token expiry time. This can be facilitated with the use of a timestamp.
Lastly the website may do periodic cleanups and archival of the trust relationships. The default case could be to not store the trust relationships and have the token expirty time force re-authentication.
No comments:
Post a Comment