*From:*Justin Richer [mailto:[email protected]]
*Sent:* Thursday, January 24, 2013 8:55 AM
*To:* Anthony Nadalin
*Cc:* [email protected]
*Subject:* Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
1. We have WebFinger lets use that as we have already been through the
discovery issues, point being there are security issues at stake here w/o
proper knowledge, next thing we know some rouge sever has signed up as a
revocation sever.
Tony, I think you're misunderstanding what I'm saying. I completely
agree that we should solve discovery and that we should use webfinger
-- but this is a bigger problem than just revocation. Let's solve
discovery for all of OAuth consistently. How would your rogue server
"sign up" as it is? Get its URL into the documentation for a service?
I think it's just as big of a problem for someone to say "hey I'm the
token endpoint" and get clients to believe it, isn't it? And it's an
even bigger problem, especially with bearer tokens, for someone to
show up and say "I'm a protected resource!". Which is exactly why I
say this needs to be solved for everything together, not just for
revocation. Would you like to volunteer to draft a webfinger profile
for all extant OAuth endpoints?
3. you can still have one if you have not used it and want to revoke it, I
may not want to redeem the auth_code to get a token to revoke it, I may just
not want to send the token
What you describe here is no longer token revocation, that's auth code
revocation. That's a different operation and shouldn't be enabled by
this endpoint. The auth code is supposed to eventually expire anyway,
and that after a fairly short period of time. If you haven't gotten a
token, you have to no token to revoke so you don't need to call the
token revocation endpoint. If you just don't want to send your token,
you just don't get to revoke it. What are you actually trying to
accomplish by this added complexity?
In any case, it's impractical to implement. It's a big -- and novel --
burden for servers to keep around auth codes and tie them to the
tokens that they represent anyway. I know our implementation doesn't
track that link, and I doubt that many others do either. The auth
codes are meant to be ephemeral.
5. That is just the point, how does one know that the token id revoked
The server will return if it's revoked the token. The effects of that
revocation may take time to propagate to all PR's, so calling it
"immediate" here could be misleading. As far as the client's
concerned, it's immediate as soon as the server returns. This is why
the client must throw the token out.
6. very poor choice, as no one know what is going on
7. No I'm not conflating things here at all, please read the text. If I send a access_token and
the server's policy says that the refresh_token associated with the access_token is also to be
revoked then I have no way to know that "The client MUST NOT use this token again after
revocation". What is "this" mean in the sentence, only the token I sent or any
revoked token. Also how do I know when the token is actually revoked, could take a week or more
given policy?
... no, you've got it backwards. Revoking an *access token* doesn't
revoke the *refresh token* (that wouldn't make much sense), but
revoking a *refresh token* SHOULD revoke all *associated access
tokens*. That's the what the implementor's note (section 3) says. As
far as the client is concerned, that token is dead the moment it gets
back a positive response from the revocation endpoint. The "this
token" in that sentence above is the token that was sent in with the
request, there's no guarantee of what happens with "related" tokens.
However, it's a good idea for the server to also throw out active
access tokens associated with a refresh token, thus the implementor's
note.
Sure, the token could be good for another week, but the client won't
care because it's thrown things out. It's not the client's problem
anymore. An immediacy requirement at the server is unimplementable in
distributed systems. Any related tokens that happened to be revoked
that the client tries to use (such as an access token tied to a
refresh token that the client just revoked) might fail if the client
uses them again.
But the thing is, failed token requests aren't a big deal, because you
just start doing OAuth again. The code path is very simple and
straightforward and is exactly the same whether or not you're using
the revocation endpoint.
-- Justin
-----Original Message-----
From: Justin Richer [mailto:[email protected]]
Sent: Thursday, January 24, 2013 8:13 AM
To: Anthony Nadalin
Cc:[email protected] <mailto:[email protected]>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
On 01/24/2013 10:58 AM, Anthony Nadalin wrote:
1. we keep punting on discovery, this has an impact on security of
where I send my credentials and token, can't see punting yet again
here
It doesn't make any sense to solve discovery *just* for revocation, which
you seem to be advocating. Of course it has an impact on security
-- this is a security protocol we're talking about, that goes without
saying. It also impacts security where I send the user for authorization, and
everything else that you do.
I would rather see discovery solved properly for all of OAuth including all
of its endpoints. UMA has taken a crack at this, there's a draft defining XRD
link types, OIDC has a solution for this as well (in the provider configuration
.well-known doc).
2. OK, make this explicit in specification
Fair enough. Got specific language to suggest?
3. if you have an auth_code you should be able to use it, agree not
all will have it but some will
You shouldn't have an auth code anymore -- you're supposed to throw it away
since it's single use (per 10.5 of RFC6749). Why wouldn't you just use the
token? You're guaranteed to have the token in all cases. I see no value in
sometimes sending an auth code and sometimes sending a token when I am
guaranteed to always have the token.
4. MAY seems a better choice
Possibly -- I think SHOULD is fine here but I'm curious what others say.
5. Make it explicit in the spec one way or the other, too vague now
Explicit how? It can explicitly go either way. From the client's
perspective, it's supposed to be immediate. From the server's perspective, it
could take a while to actually enforce that.
6. How does one find the policy, as this has an impact on #7
How does one find any other implementation specific policy? There was
already a big discussion about this a while ago. It used to be a MUST to
cascade, then as I recall, Google objected to it because their access tokens in
the wild can't be revoked at all, so revoking a refresh token revokes only that
token. The current language allows the server to decide what it has to do.
7. There is a big difference here in enforcement, the client should
not have to enforce this rule, the client may not know due to policy
that revoking 1 token revokes other tokens thus the client would have
to know the servers policy. This should be a SHOULD not MUST
You're conflating things here. If the client revokes the refresh token,
they must not use that refresh token again. They can try to use any access or
other tokens if they want to, but that refresh token is off the table. The
server is allowed to also nuke any access tokens that it wants to, but if the
client wants to be really, really sure, it can revoke all of its access tokens
separately.
-- Justin
-----Original Message-----
From: Justin Richer [mailto:[email protected]]
Sent: Thursday, January 24, 2013 6:17 AM
To: Anthony Nadalin
Cc:[email protected] <mailto:[email protected]>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
Not to jump in and answer for Torsten, but I thought I'd offer at
least my understanding of the document:
On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
1. Since not stated I assume that the Revocation Endpoint can
exist on a different server from the Authorization server (or is it assumed
that they are 1), if so how is the Revocation Endpoint found?
It could be separate if your architecture can support that. It gets
found the same way other OAuth endpoints get found -- configuration documents,
some kind of discovery mechanism, or magic. Which is to say, that's not
currently OAuth's problem.
2. Any token type that is supported can be revoked, including
refresh token ?
That's the idea. We've implemented this on our OIDC server so that you
can also revoke ID Tokens for session management purposes.
3. Why does one have to send the token, can't this just be an
auth_code ?
You don't always use an auth code to get a token (think implicit,
client credentials, assertion, or resource owner credentials flows), and auth
codes are supposed to be thrown away after use anyway.
4. Says CORS SHOULD be supported, I think a MAY be better
here since a site may have issues supporting CORS
If they have issues, which is to say "A good reason not to", then they don't have
to support it. That's the semantics behind "SHOULD", and so it is fine here.
5. Does not say but is the revocation to be immediate upon
the return of the request ?
This is implementation dependent. Large scale distributed implementations could
have trouble making this "immediate", but small systems are more likely to be
quick. From the client's perspective, if they get back a success response, they shouldn't
count on that token being good anymore (see section 2 note about client behavior).
6. Does the revocation of the access token also revoke the
refresh token (if it was provided) ? Or is this a revocation policy decision ?
That's a policy decision.
7. Section 2 says "the client MUST NOT use this token again",
well that seems odd, not sure this should be here as the client could try to use it gain,
there is no need to put support in client to prevent this.
Why would a client want to use a token that they just revoked? This is
prescribing the desired correct behavior to a client so that client developers
will do the right thing when they implement it. Isn't that the point of the
spec?
-- Justin
