Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
Thanks Mike, I think changing the example would be helpful. However I think that including some text along the lines of what James suggested would also be very valuable. I agree that the connection between OAuth and Bearer could and should be made more explicit. And that the implications of the b64token syntax, particularly on what AS can use to construct ATs, could/should be made more clear. I can propose some specific text (building on James') if others in the WG agree? On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones michael.jo...@microsoft.com wrote: I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values. I'll add it to my to-do list for any additional edits for the Bearer spec. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Monday, March 05, 2012 3:33 PM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Brian, On casual reading of The OAuth 2.0 Authorization Protocol: Bearer Tokens* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client and RS. Digging a bit deeper in to HTTP/1.1, part 7: Authentication**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token. Do I read this correctly? Yes. If so, I feel like some additional clarifying text in the Bearer Tokens draft might help avoid what is (based on my small sample) a common point of misunderstanding. Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing: Authorization: Bearer vF9dft4qmT to Authorization: Bearer vF9.dft4.qmT The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the access_token member of an access token response is the bearer token. The access_token string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the Bearer OAuth access token type is defined. Also, does the use of b64token implicitly limit the allowed characters that an AS can use to construct a bearer access token? Yes. * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 ** http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
as one of the unnamed 'confused colleagues', I'd welcome clarification paul On 3/6/12 11:23 AM, Brian Campbell wrote: Thanks Mike, I think changing the example would be helpful. However I think that including some text along the lines of what James suggested would also be very valuable. I agree that the connection between OAuth and Bearer could and should be made more explicit. And that the implications of the b64token syntax, particularly on what AS can use to construct ATs, could/should be made more clear. I can propose some specific text (building on James') if others in the WG agree? On Mon, Mar 5, 2012 at 5:32 PM, Mike Jonesmichael.jo...@microsoft.com wrote: I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values. I'll add it to my to-do list for any additional edits for the Bearer spec. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Monday, March 05, 2012 3:33 PM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Brian, On casual reading of The OAuth 2.0 Authorization Protocol: Bearer Tokens* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client and RS. Digging a bit deeper in to HTTP/1.1, part 7: Authentication**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token. Do I read this correctly? Yes. If so, I feel like some additional clarifying text in the Bearer Tokens draft might help avoid what is (based on my small sample) a common point of misunderstanding. Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing: Authorization: Bearer vF9dft4qmT to Authorization: Bearer vF9.dft4.qmT The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the access_token member of an access token response is the bearer token. The access_token string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the Bearer OAuth access token type is defined. Also, does the use of b64token implicitly limit the allowed characters that an AS can use to construct a bearer access token? Yes. * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 ** http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
I think clarification text makes sense here because we're importing a term from a foreign spec -- b64token -- that overlaps with a term meaning something quite different in our spec -- token. We can't really change either of these terms, so we need to separate them some other way. -- Justin On 03/06/2012 11:29 AM, Paul Madsen wrote: as one of the unnamed 'confused colleagues', I'd welcome clarification paul On 3/6/12 11:23 AM, Brian Campbell wrote: Thanks Mike, I think changing the example would be helpful. However I think that including some text along the lines of what James suggested would also be very valuable. I agree that the connection between OAuth and Bearer could and should be made more explicit. And that the implications of the b64token syntax, particularly on what AS can use to construct ATs, could/should be made more clear. I can propose some specific text (building on James') if others in the WG agree? On Mon, Mar 5, 2012 at 5:32 PM, Mike Jonesmichael.jo...@microsoft.com wrote: I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values. I'll add it to my to-do list for any additional edits for the Bearer spec. -- Mike -Original Message- From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Monday, March 05, 2012 3:33 PM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Brian, On casual reading of The OAuth 2.0 Authorization Protocol: Bearer Tokens* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client and RS. Digging a bit deeper in to HTTP/1.1, part 7: Authentication**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token. Do I read this correctly? Yes. If so, I feel like some additional clarifying text in the Bearer Tokens draft might help avoid what is (based on my small sample) a common point of misunderstanding. Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing: Authorization: Bearer vF9dft4qmT to Authorization: Bearer vF9.dft4.qmT The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the access_token member of an access token response is the bearer token. The access_token string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the Bearer OAuth access token type is defined. Also, does the use of b64token implicitly limit the allowed characters that an AS can use to construct a bearer access token? Yes. *http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 ** http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Securing APIs with OAuth 2.0
OK. Thanks for the explanations so far. It's very helpful. I'm prototyping the framework support for OAuth 2.0 and at this stage I'm trying to figure out what exactly the runtime itself can do and what has to be delegated to the custom code and thus how to design the api the runtime and the custom code will use to communicate with each other. Makes sense. It's often hard to figure out exactly where to draw the lines of abstraction for fundamental libraries like this. Let me ask one more question, sorry if it's a silly one :-) So suppose a given client has been pre-authorized by the end user. Next, the client can get the pre-authorized token via the authorization code flow or the implicit code flow (ignoring the client_credentials one for the moment). Does it make sense to restrict which flow a given pre-authorized token can 'work' with ? Example, enforce that the pre-authorized token can only be issued to the clients initiating an authorization code flow but not to those trying an implicit one, or vice versa ? The reason I ask is that I'm thinking that the entity representing an access token should have a property indicating which grant type was used for this token being created in the first place. So if such a token were to represent the user pre-authorizing the client and then eventually given to a client via the authorization code or implicit code flow, then this token would actually need to be cloned each time for a specific grant type property be set, and this does not look optimal... Several implementations that I've seen do restrict the flows that a given client is allowed to do. Any time you have a privileged client, such as one that's been auto-approved, it makes even more sense to lock it down in other avenues. You don't have to encode it into the token or code, but of course if you have a structured token format you may do that. Note that with the code flow, you probably don't actually generate the token until the client shows up with a valid code and client id/secret, but that's really a runtime optimization that's going to be specific for your setup. All you really need is a flag at your AS that ties the given client id to a set of allowable grant types. When the client shows up at the AS endpoints, you look up this flag based on the client ID and verify that the flow you're doing matches up with what's allowed by configuration. -- Justin ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
Yeah, something as simple as, Note that the name 'b64token' does not imply base64 encoding, see the definition in [[INSERT REFERENCE HERE]]. would do it. -bill From: Brian Campbell bcampb...@pingidentity.com To: Mike Jones michael.jo...@microsoft.com Cc: oauth oauth@ietf.org Sent: Tuesday, March 6, 2012 8:23 AM Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Thanks Mike, I think changing the example would be helpful. However I think that including some text along the lines of what James suggested would also be very valuable. I agree that the connection between OAuth and Bearer could and should be made more explicit. And that the implications of the b64token syntax, particularly on what AS can use to construct ATs, could/should be made more clear. I can propose some specific text (building on James') if others in the WG agree? On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones michael.jo...@microsoft.com wrote: I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values. I'll add it to my to-do list for any additional edits for the Bearer spec. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Monday, March 05, 2012 3:33 PM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Brian, On casual reading of The OAuth 2.0 Authorization Protocol: Bearer Tokens* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client and RS. Digging a bit deeper in to HTTP/1.1, part 7: Authentication**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token. Do I read this correctly? Yes. If so, I feel like some additional clarifying text in the Bearer Tokens draft might help avoid what is (based on my small sample) a common point of misunderstanding. Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing: Authorization: Bearer vF9dft4qmT to Authorization: Bearer vF9.dft4.qmT The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the access_token member of an access token response is the bearer token. The access_token string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the Bearer OAuth access token type is defined. Also, does the use of b64token implicitly limit the allowed characters that an AS can use to construct a bearer access token? Yes. * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 ** http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
