I embed an OAuth2 authorization code stream in an application with a proof of concept - this way pure ASP.NET MVC without using DotNetOpenAuth or any other auth framework, and I scratch my head on how to handle the recall.
My implementation works like this:
- The user logs into FooApp (OAuth2 Client Application - Website).
- FooApp redirects user to www.myserver.com/accounts/authorize
- The user says: "yep, FooApp can access my content"
- I create an authorization code and save this code on myserver.com along with the client ID, user ID and areas that the user authorized. (In my implementation, the authorization code is the GUID key of the database entry that authorized that.)
- User is redirected back to FooApp
- FooApp makes an HTTP request to MyServer, including an authorization code
- MyServer looks for this authorization code, verifies that it is valid and has not expired. It marks the authorization code as used - because OAuth2 authorization codes MUST be one-time and short-lived, and then responds to FooApp with a refresh token and access token
- FooApp uses access_token to access user data. When access_token expires after 10 minutes, FooApp uses refresh_token to get another.
- After a couple of weeks, the user decides that they are tired of FooApp to access their data, so they log in to MyServer and invalidate FooApp.
OK, here, when the specification becomes a little fuzzy in the recommended implementation, and I think it comes down to what happens when the user cancels authorization.
Option 1:
The update current is an autonomous encrypted string containing the user ID, client ID, and scope. It is not stored anywhere. When the access token expires, the client sends me an update token. I will decrypt this and check if I still have a valid authorization entry in the file for this user / client / area combination. If I do, I will send them a new access token. If not, I return an invalid_grant error.
In this case, cancellation of authorization would mean marking. The authorization record in my database is canceled (or simply deleted entirely). No authorization entry → update tokens will not work → FooApp can no longer access data.
Option 2:
I store the update token in my database along with client_id, user ID and scope allowed in this token. When I receive a request to update the token, I find the refresh_token entry, check if it has been canceled, etc.
In this case, “revocation of authorization” will be implemented by marking> the update token in my database as canceled or by deleting it.
In addition, in this case, I see no reason to save authorization in a file after exchanging it for tokens. If a user wants to know which applications have access to their MyServer data, I simply request a database for all of their unverified update tokens and related areas.
As far as I can tell, any option meets the requirements of the OAuth2 specification, allowing users to view and revoke all authorizations that are currently active on their MyServer account. One limitation is that option 1 will not allow multiple separate OAuth2 tokens to be issued to the same client for the same user, but I cannot think of any scenario in which you would like to do this.
What would you recommend? Encrypt tokens and save permissions? Delete authorization after use and save update tokens? Or does it really not matter?