+2 1c introduces one more token that needs to be managed, both by the client and by the server.
1a/b/c has one more issue, tokens are more exposed than usual and if revocation fails this can be problematic. Both access and refresh tokens should be revocable, right? Thanks, Marius On Wed, Aug 18, 2010 at 6:04 AM, Stefanie Dronia <[email protected]> wrote: > Hi Torsten, > > ++2. No care about token formats or URL length problem. > > -1: all options bring some problems along (as you already indicated). > Additionally, an overloading of HTTP DELETE (as Igor mentioned) is not an > option from my point of view. Every overloading would be deployment specific > (or has to be defined by the OAuth spec???) and I doubt that it is possible > to overload this method with widely-used frameworks. > > -1c: Introduction of token ids: If a token is addressed by its ID, it is IMO > not possible to verify in all cases that the client (who requests > revocation/modification) is same client that the token was issued for before > if the authorization server is stateless. So someone might catch a token and > then revokes it. > May there be other security issues? > Another drawback is that the access token response has to be extended. > > What kind of modifications of tokens do you have in mind? (as you commented > with 1c) > > Regards, > Stefanie > > > Am 16.08.2010 23:09, schrieb Torsten Lodderstedt: >> >> Hi all, >> >> I intend to submit a I-D for token revocation. Based on previous >> discussions on the mailing list and here at Deutsche Telekom, I see a couple >> of design options. I would like to share those options with the WG and try >> to reach consensus on a single option before investing the time to write the >> I-D. >> >> 1) HTTP Delete on tokens endpoint >> >> DELETE seems a natural way for revoking (deleting) tokens. Although the >> HTTP spec is a bit vaque in this concern, current practice prohibits a body >> for DELETE requests. So the token must be addressed by the request's URI. >> Lets assume the token is passed as URI query parameter as follows: >> >> DELETE /tokens?refresh_token=8xLOxBtZp8&&&# HTTP/1.1 >> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >> >> But is it advisable to pass tokens as URI query parameters? The current >> character set definition for access tokens (§5.1.1) is not URL-safe since it >> includes URI reserved characters (e.g. '/'). Additionally, there is no >> definition of a refresh tokens character set. So compliant authorization >> servers could issue tokens, which cannot be safely passed as URI query >> parameters. >> >> Note: As an additional challenge, self-contained tokens can be very large. >> So passing them as URI parameter may exceed URL length limits. >> >> I see the following alternatives to cope with the encoding problem: >> >> a) Force usage of a URL-safe character set for access and request tokens. >> - rather restrictive, will most likely collide with existing token formats >> - does not solve URL length problem >> >> b) Force base64-URL-safe encoding for all tokens on transit. >> - does not solve URL length problem >> - significant API change >> >> c) Authorization servers supporting revocation may additionally issue a >> URL-safe token id in the access token response. This id is used to reference >> the token in DELETE requests. >> >> HTTP/1.1 200 OK >> Content-Type: application/json >> Cache-Control: no-store >> { >> "access_token":"SlAV32hkKG/hhh/&%", >> "access_token_id":"234567890", >> "expires_in":3600, >> "refresh_token":"8xLOxBtZp8&&&#&", >> "refresh_token_id":"asdfghjklhgf" >> } >> >> >> DELETE /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 >> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >> >> Note: Since tokens become addressable resources on the authz server, one >> could also query or modify token data using a GET/PUT requests >> >> GET /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 >> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >> >> HTTP/1.1 200 OK >> Content-Type: application/json >> Cache-Control: no-store >> >> { >> "scope":"abc", >> "issued_on":"08/11/2010", >> "last_usage":"08/13/2010" } >> >> >> 2) HTTP Post on dedicated revocation endpoint >> >> An additional endpoint is used to revoke tokens. The token to be revoked >> is sent as request body parameter. >> >> POST /revocation HTTP/1.1 >> Host: server.example.com >> Content-Type: application/x-www-form-urlencoded >> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >> >> refresh_token=n4E9O119d >> >> This option requires some support for the client to discover the >> revocation endpoint. >> >> Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest >> additional design options. >> >> regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
