IW OAuth2 Question

[Alexandre Machado]

For the sake of keeping this conversation public, so other people can benefit from it, I'll post here some information that Ioan and I exchanged via e-mail:

First, Ioan pointed me out this SO post where an user has a similar problem:

https://stackoverflow.com/questions/3594...cess-token


Then, this was basically my response:

The question that you pointed out has a slightly different nature. In that question case, they are interested in finding out if the token abc123 was actually issued granting access to joe@doe.com, because in that example the user is building an API which has no control over the authorization code request. The token is received in every request and needs to be checked.


In our case, the authorization code request is always done by IntraWeb itself, so you can always know whether a received token is valid or not for user joe@doe.com, as long as you keep this information stored somewhere (and you're able to retrieve it even if the session expires or application restarts, thus a database is ideal).
So, in theory, we don't need to validate a token (i.e. check if the token is a valid one or a forged one) because we just need to compare it against the tokens that we have already requested/received ourselves.

However, I understand your problem. It could be summarized like this:
1) The user logs into your application for the first time (so we have now a valid token abc123 for joe@doe.com)
2) In the following hours or days the user could
  2a) Log off from his google account on that device, or
  2b) Revoke permission for your application to access his private profile/data

If the user does that while his IW session is still active, there is basically nothing that we can do, so his access is considered valid until the current session expires. In all subsequent accesses (i.e. after his first session expired), there are 2 possible ways of handling the access authorization:

a) You ignore (2a) and (2b) events above and continue to grant access to your application as long as the user doesn't explicitly log off from it. In this case you should remove the "access cookie" (the cookie which relates to the access token that I mentioned in my previous email). Then, next time the user tries to log in, it will be prompted again with the Google login. This is how some applications handle this.

b) Every time the user comes back to your application you validate the existing access token (that you saved somewhere and retrieved based on the access cookie received from the user browser) and, if the access token is valid, you can grant access to that user.

As I understood from your request, you would likely go with option (b).

The problem with option (b) above is that OAuth access tokens have a very short life, in general only 1 hour (some APIs allow certain flexibility but it won't cover our needs here, I'm afraid). So, let's say that an access token is obtained now, and 4 hours later the user comes back for a new session. When verified against google API, this token will be rejected with an "invalid_value" error message, which is not enough for our needs either. For instance, in some APIs there is no way to differentiate a fake access token from a legitimate, although expired one.

The solution here, I believe, would be handled in 2 steps:

i) Try to validate the access token using the token info endpoint (or the graph endpoint on Azure). If the access token is not expired, the access will be granted and the authorization process is done. Otherwise, if the access token is not valid (expired, invalid, whatever) we:

ii) Request a new access token from the token endpoint as we did in the first user access, however without requesting the user to explicitly grant access. Both Google and Azure APIs support the "passive" consent, such that the new access token will be generated if the user has previously granted access to that application using that browser/device and the user is currently logged in to his Google or Microsoft account.

Having said that, in the next release we are extending the OAuth support even further, including Facebook API and other features that will allow to handle case (2) above easily.

We are also re-writing the demo application to be a comprehensive one, showing how to deal with this issue.

Cheers