Re: [OAUTH-WG] Token introspection for public clients?
Okay, I understand more of the intent of this document now. I will say that the first time I read it, it was not at all clear that it was not intended for OAuth 2.0 clients to use this endpoint. It seems now that it is only intended for internal servers to use, such as when a resource server is verifying an access token. I think the part that threw me off was that OAuth 2.0 client authentication was mentioned as one of the mechanisms of providing authorization to use the introspection endpoint: https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#section-2.1 Hopefully that feedback is helpful. That said, I also agree with William's assessment. Aaron Parecki aaronparecki.com @aaronpk http://twitter.com/aaronpk On Tue, Jul 21, 2015 at 4:05 PM, William Denniss wdenn...@google.com wrote: We had a good sync on this topic offline on Monday, and it seemed the consensus was that if clients need to introspect access tokens they are doing something wrong. That said, looking only at the resource server use-case, I still think the MUST is problematic. The out of band authentication requirement when accompanied with the MUST makes the spec less useful. i.e. the endpoint MUST also require some form of authorization to access this endpoint, but The specifics of this authentication credentials are out of scope of this specification. This makes dynamic discovery which was mentioned as potentially applying to this spec virtually useless (you discovered the introspection endpoint, but how do you discover how to authenticate?). It also adds to general implementation complexity. Brian mentioned that in their implementation, they decided not to force authentication for introspection by resource servers as they were protecting the endpoint through other means, and wanted to reduce complexity for developers. The MUST here constrains that decision, one which I think should be left up to the provider. Lastly, the MUST is presented in the spec as being required to prevent token scanning, and yet there are other ways to mitigate that attack. If there are better reasons than token scanning for this remaining a MUST, then I think the spec should document them. Side note: If you prevent token scanning through other means, the main benefit of still requiring authentication seems to be preventing information leaking out to a client who is in possession of the access token but isn't the intended audience. This may or may not be an issue depending on the contents of the introspection response. Perhaps it would be good to mention this in the security considerations, as it's something that should be considered by implementors. Given the sensitivity of information revealed by the introspection endpoint varies, I don't think that this alone would mandate the MUST. On Tue, Jul 21, 2015 at 10:03 AM, Justin Richer jric...@mit.edu wrote: Just use the token at your target API and see if it works. Your client’s going to need to be able to get a new token if this one expires mid-session anyway, so you’re not saving anything by doing an introspection request. — Justin On Jul 20, 2015, at 9:34 PM, Aaron Parecki aa...@parecki.com wrote: I'm looking for a way to check if an existing token is still valid. Imagine a client is holding on to a token between user sessions, for example if it's making API requests for the user on a cron job. When the user returns to the site, I want to check if the token is still valid, and make them sign in again if not. Aaron On Mon, Jul 20, 2015 at 12:11 PM John Bradley ve7...@ve7jtb.com wrote: If you want the resource owner/user then get a id_token from the token endpoint. That saves another call to a introspection endpoint. Sent from my iPhone On Jul 20, 2015, at 7:49 PM, Aaron Parecki aa...@parecki.com wrote: Okay, if the intent is for this endpoint to be used by the resource server, this all makes sense. I was under the impression that it could also be used by clients to verify if the token is valid. Is there some other spec I could look at that is intended to be used by clients to verify if a token is valid and find out the user ID associated with it? Aaron Parecki aaronparecki.com @aaronpk http://twitter.com/aaronpk On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William
Re: [OAUTH-WG] Token introspection for public clients?
Hi Would there be any sense at all to have a new endpoint dedicated to supporting public clients only for these clients be able to do the extra validation which only public clients may need, etc, etc. Or perhaps let the access token endpoint not only exchange grants but also do some optional follow-up validation of the token properties for public clients given that the access token endpoint can support public clients and is dedicated to working with the clients. Purely from a technical point of view it seems not a big deal to relax it back to SHOULD, but I wonder if having the introspection endpoint supporting different roles (public clients, resource servers, with some requiring the auth and some not) would make it more difficult to do the extra work for getting PoP token introspection supported, etc... My 2c, thanks, Sergey On 22/07/15 02:05, William Denniss wrote: We had a good sync on this topic offline on Monday, and it seemed the consensus was that if clients need to introspect access tokens they are doing something wrong. That said, looking only at the resource server use-case, I still think the MUST is problematic. The out of band authentication requirement when accompanied with the MUST makes the spec less useful. i.e. the endpoint MUST also require some form of authorization to access this endpoint, but The specifics of this authentication credentials are out of scope of this specification. This makes dynamic discovery which was mentioned as potentially applying to this spec virtually useless (you discovered the introspection endpoint, but how do you discover how to authenticate?). It also adds to general implementation complexity. Brian mentioned that in their implementation, they decided not to force authentication for introspection by resource servers as they were protecting the endpoint through other means, and wanted to reduce complexity for developers. The MUST here constrains that decision, one which I think should be left up to the provider. Lastly, the MUST is presented in the spec as being required to prevent token scanning, and yet there are other ways to mitigate that attack. If there are better reasons than token scanning for this remaining a MUST, then I think the spec should document them. Side note: If you prevent token scanning through other means, the main benefit of still requiring authentication seems to be preventing information leaking out to a client who is in possession of the access token but isn't the intended audience. This may or may not be an issue depending on the contents of the introspection response. Perhaps it would be good to mention this in the security considerations, as it's something that should be considered by implementors. Given the sensitivity of information revealed by the introspection endpoint varies, I don't think that this alone would mandate the MUST. On Tue, Jul 21, 2015 at 10:03 AM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: Just use the token at your target API and see if it works. Your client’s going to need to be able to get a new token if this one expires mid-session anyway, so you’re not saving anything by doing an introspection request. — Justin On Jul 20, 2015, at 9:34 PM, Aaron Parecki aa...@parecki.com mailto:aa...@parecki.com wrote: I'm looking for a way to check if an existing token is still valid. Imagine a client is holding on to a token between user sessions, for example if it's making API requests for the user on a cron job. When the user returns to the site, I want to check if the token is still valid, and make them sign in again if not. Aaron On Mon, Jul 20, 2015 at 12:11 PM John Bradley ve7...@ve7jtb.com mailto:ve7...@ve7jtb.com wrote: If you want the resource owner/user then get a id_token from the token endpoint. That saves another call to a introspection endpoint. Sent from my iPhone On Jul 20, 2015, at 7:49 PM, Aaron Parecki aa...@parecki.com mailto:aa...@parecki.com wrote: Okay, if the intent is for this endpoint to be used by the resource server, this all makes sense. I was under the impression that it could also be used by clients to verify if the token is valid. Is there some other spec I could look at that is intended to be used by clients to verify if a token is valid and find out the user ID associated with it? Aaron Parecki aaronparecki.com http://aaronparecki.com/ @aaronpk http://twitter.com/aaronpk On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing
Re: [OAUTH-WG] Token introspection for public clients?
Just use the token at your target API and see if it works. Your client’s going to need to be able to get a new token if this one expires mid-session anyway, so you’re not saving anything by doing an introspection request. — Justin On Jul 20, 2015, at 9:34 PM, Aaron Parecki aa...@parecki.com wrote: I'm looking for a way to check if an existing token is still valid. Imagine a client is holding on to a token between user sessions, for example if it's making API requests for the user on a cron job. When the user returns to the site, I want to check if the token is still valid, and make them sign in again if not. Aaron On Mon, Jul 20, 2015 at 12:11 PM John Bradley ve7...@ve7jtb.com mailto:ve7...@ve7jtb.com wrote: If you want the resource owner/user then get a id_token from the token endpoint. That saves another call to a introspection endpoint. Sent from my iPhone On Jul 20, 2015, at 7:49 PM, Aaron Parecki aa...@parecki.com mailto:aa...@parecki.com wrote: Okay, if the intent is for this endpoint to be used by the resource server, this all makes sense. I was under the impression that it could also be used by clients to verify if the token is valid. Is there some other spec I could look at that is intended to be used by clients to verify if a token is valid and find out the user ID associated with it? Aaron Parecki aaronparecki.com http://aaronparecki.com/ @aaronpk http://twitter.com/aaronpk On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com mailto:wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because clients shouldn’t be doing the introspection in the first place — the whole spec is there to support resource servers introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t
Re: [OAUTH-WG] Token introspection for public clients?
Why does your client need/want to read the token? Phil @independentid www.independentid.com phil.h...@oracle.com On Jul 20, 2015, at 9:34 AM, William Denniss wdenn...@google.com wrote: Even if the primary target is the protected resource, is there a reason to exclude use by clients? The stated reason for this requirement in the spec is to prevent token scanning, but there are other ways to prevent that. On Mon, Jul 20, 2015 at 7:01 AM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com mailto:wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because clients shouldn’t be doing the introspection in the first place — the whole spec is there to support resource servers introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result came back — you could easily give a suspected attacker valid-looking-but-fake data as one mitigation mechanism.) The introspection response can give you information about where else the token could be used, potentially. Additionally, the RS really ought to be preventing data-fishing attacks like this just for its own sake anyway. There are lots of techniques for doing this, but they tend to be specific to the kind of API that’s being served. Requiring the resource server to authenticate with the authorization server also allows you to do a few other useful things. Our implementation, for example, limits the token information that is returned to a particular AS. This allows us
Re: [OAUTH-WG] Token introspection for public clients?
Apologies, I did not mean read, but introspect the token. Phil @independentid www.independentid.com phil.h...@oracle.com On Jul 20, 2015, at 9:38 AM, Phil Hunt phil.h...@oracle.com wrote: Why does your client need/want to read the token? Phil @independentid www.independentid.com http://www.independentid.com/phil.h...@oracle.com mailto:phil.h...@oracle.com On Jul 20, 2015, at 9:34 AM, William Denniss wdenn...@google.com mailto:wdenn...@google.com wrote: Even if the primary target is the protected resource, is there a reason to exclude use by clients? The stated reason for this requirement in the spec is to prevent token scanning, but there are other ways to prevent that. On Mon, Jul 20, 2015 at 7:01 AM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com mailto:wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because clients shouldn’t be doing the introspection in the first place — the whole spec is there to support resource servers introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result came back — you could easily give a suspected attacker valid-looking-but-fake data as one mitigation mechanism.) The introspection response can give you information about where else the token could be used, potentially. Additionally, the RS really ought to be preventing data-fishing attacks like this just for its own sake anyway. There are lots of techniques for doing this, but they tend to be specific
Re: [OAUTH-WG] Token introspection for public clients?
In OAuth, the token is opaque to the client. Clients in general don’t need to know the kinds of token information that’s returned from the introspection endpoint. Clients already get information about scopes and expiration from the token endpoint, what else do they need? If they need more information, this should be specified as an extension to the token endpoint, in my opinion. Note that early drafts of this document targeted both clients and protected resources, but after discussion with both implementors and the working group, this was pulled back to just the resource server because that’s what people are doing with it. A single piece of software can be both an OAuth client and an OAuth protected resource, but those are two different roles in the system and shouldn’t be conflated. — Justin On Jul 20, 2015, at 9:34 AM, William Denniss wdenn...@google.com wrote: Even if the primary target is the protected resource, is there a reason to exclude use by clients? The stated reason for this requirement in the spec is to prevent token scanning, but there are other ways to prevent that. On Mon, Jul 20, 2015 at 7:01 AM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com mailto:wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because clients shouldn’t be doing the introspection in the first place — the whole spec is there to support resource servers introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result
Re: [OAUTH-WG] Token introspection for public clients?
Hi, I've always thought OAuth2 clients are out of the picture here, except that the resource server needs to introspect a client's token and it (the resource server) needs to authenticate to the introspection endpoint. Letting the actual OAuth2 clients (confidential or public ones) also introspect the endpoint would indeed conflate the roles, and overload the access token response protocol which provides all the info the actual client needs to know. The client only need to know the token info that lets it talk to the resource server, it does not need to introspect it like resource server does in order to make an authorization decision. +1 to what Justin says... Cheers, Sergey On 20/07/15 10:39, Justin Richer wrote: In OAuth, the token is opaque to the client. Clients in general don’t need to know the kinds of token information that’s returned from the introspection endpoint. Clients already get information about scopes and expiration from the token endpoint, what else do they need? If they need more information, this should be specified as an extension to the token endpoint, in my opinion. Note that early drafts of this document targeted both clients and protected resources, but after discussion with both implementors and the working group, this was pulled back to just the resource server because that’s what people are doing with it. A single piece of software can be both an OAuth client and an OAuth protected resource, but those are two different roles in the system and shouldn’t be conflated. — Justin On Jul 20, 2015, at 9:34 AM, William Denniss wdenn...@google.com mailto:wdenn...@google.com wrote: Even if the primary target is the protected resource, is there a reason to exclude use by clients? The stated reason for this requirement in the spec is to prevent token scanning, but there are other ways to prevent that. On Mon, Jul 20, 2015 at 7:01 AM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com mailto:wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because *clients* shouldn’t be doing the introspection in the first place — the whole
Re: [OAUTH-WG] Token introspection for public clients?
Any good access token implementation should make such scanning totally infeasible (via sufficient entropy in the token, if it's a reference, or cryptographic protections, if it's self contained). Authentication/authorization at the introspection endpoint, in my view anyway, is more about privacy and preventing certain types of information disclosure (maybe a client seeing info in an encrypted token or opaque reference token). We implemented introspection type functionality in our initial OAuth product support well before the WG introspection document existed. It's got basically similar concepts but just with a different syntax and endpoint. The original release of it required authentication but we later relaxed that requirement based on deployment feedback. So that's a data-point based on experience that's maybe worth considering. Though I realize the document is probably too far along in the process for changes at this point. On Mon, Jul 20, 2015 at 9:34 AM, William Denniss wdenn...@google.com wrote: Even if the primary target is the protected resource, is there a reason to exclude use by clients? The stated reason for this requirement in the spec is to prevent token scanning, but there are other ways to prevent that. On Mon, Jul 20, 2015 at 7:01 AM, Justin Richer jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because *clients* shouldn’t be doing the introspection in the first place — the whole spec is there to support *resource servers* introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result
Re: [OAUTH-WG] Token introspection for public clients?
Okay, if the intent is for this endpoint to be used by the resource server, this all makes sense. I was under the impression that it could also be used by clients to verify if the token is valid. Is there some other spec I could look at that is intended to be used by clients to verify if a token is valid and find out the user ID associated with it? Aaron Parecki aaronparecki.com @aaronpk http://twitter.com/aaronpk On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because *clients* shouldn’t be doing the introspection in the first place — the whole spec is there to support *resource servers* introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result came back — you could easily give a suspected attacker valid-looking-but-fake data as one mitigation mechanism.) The introspection response can give you information about where else the token could be used, potentially. Additionally, the RS really ought to be preventing data-fishing attacks like this just for its own sake anyway. There are lots of techniques for doing this, but they tend to be specific to the kind of API that’s being served. Requiring the resource server to authenticate with the authorization server also allows you to do a few other useful things. Our implementation, for example, limits the token information that is returned to a particular AS. This allows us to have tokens that can be used in multiple RS’s without those RS’s ever even knowing the token is powerful enough to be used
Re: [OAUTH-WG] Token introspection for public clients?
You get the AT validity period with the token expires_in. The Refresh token doesn't expire. A token could be revoked in less than the expiry time but you discover that by using it. If you get a error on the API using the AT then you make the user re authorize you via the Authorization endpoint. If it is a sticky grant you could use prompt=none in a iframe to see if the user is logged in. I don’t see a introspection endpoint for the client adding anything in reality. It may cause problems if clients start sniffing the content of AT and information is leaked or people start making decisions based on a token that is supposed to be opaque. John B. On Jul 20, 2015, at 9:34 PM, Aaron Parecki aa...@parecki.com wrote: I'm looking for a way to check if an existing token is still valid. Imagine a client is holding on to a token between user sessions, for example if it's making API requests for the user on a cron job. When the user returns to the site, I want to check if the token is still valid, and make them sign in again if not. Aaron On Mon, Jul 20, 2015 at 12:11 PM John Bradley ve7...@ve7jtb.com mailto:ve7...@ve7jtb.com wrote: If you want the resource owner/user then get a id_token from the token endpoint. That saves another call to a introspection endpoint. Sent from my iPhone On Jul 20, 2015, at 7:49 PM, Aaron Parecki aa...@parecki.com mailto:aa...@parecki.com wrote: Okay, if the intent is for this endpoint to be used by the resource server, this all makes sense. I was under the impression that it could also be used by clients to verify if the token is valid. Is there some other spec I could look at that is intended to be used by clients to verify if a token is valid and find out the user ID associated with it? Aaron Parecki aaronparecki.com http://aaronparecki.com/ @aaronpk http://twitter.com/aaronpk On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com mailto:wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because clients shouldn’t be doing the introspection in the first place — the whole spec is there to support resource servers introspecting at the auth server. So you probably don’t have “public client resource
Re: [OAUTH-WG] Token introspection for public clients?
I'm looking for a way to check if an existing token is still valid. Imagine a client is holding on to a token between user sessions, for example if it's making API requests for the user on a cron job. When the user returns to the site, I want to check if the token is still valid, and make them sign in again if not. Aaron On Mon, Jul 20, 2015 at 12:11 PM John Bradley ve7...@ve7jtb.com wrote: If you want the resource owner/user then get a id_token from the token endpoint. That saves another call to a introspection endpoint. Sent from my iPhone On Jul 20, 2015, at 7:49 PM, Aaron Parecki aa...@parecki.com wrote: Okay, if the intent is for this endpoint to be used by the resource server, this all makes sense. I was under the impression that it could also be used by clients to verify if the token is valid. Is there some other spec I could look at that is intended to be used by clients to verify if a token is valid and find out the user ID associated with it? Aaron Parecki aaronparecki.com @aaronpk http://twitter.com/aaronpk On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because *clients* shouldn’t be doing the introspection in the first place — the whole spec is there to support *resource servers* introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result came back — you could easily give a suspected attacker valid-looking-but-fake data as one mitigation mechanism.) The introspection response can give you information about where else the
Re: [OAUTH-WG] Token introspection for public clients?
If you want the resource owner/user then get a id_token from the token endpoint. That saves another call to a introspection endpoint. Sent from my iPhone On Jul 20, 2015, at 7:49 PM, Aaron Parecki aa...@parecki.com wrote: Okay, if the intent is for this endpoint to be used by the resource server, this all makes sense. I was under the impression that it could also be used by clients to verify if the token is valid. Is there some other spec I could look at that is intended to be used by clients to verify if a token is valid and find out the user ID associated with it? Aaron Parecki aaronparecki.com @aaronpk On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because clients shouldn’t be doing the introspection in the first place — the whole spec is there to support resource servers introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result came back — you could easily give a suspected attacker valid-looking-but-fake data as one mitigation mechanism.) The introspection response can give you information about where else the token could be used, potentially. Additionally, the RS really ought to be preventing data-fishing attacks like this just for its own sake anyway. There are lots of techniques for doing this, but they tend to be specific to the kind of API that’s being served. Requiring the resource server to authenticate with the authorization server also allows you
Re: [OAUTH-WG] Token introspection for public clients?
That is one of the place that using a POP mechanism may be useful. If the client has established a key with the AS that issued the original token say via PKCE then, then it may be possible to bind the token being exchanged to the party exchanging it even if the exchanger has no pre exchanged credentials with the token exchange endpoint. In the ACDC proposal part of profiling the assertion exchange was to require that they be POP tokens using PKCE as the confirmation method. I would like to think that the ACDC use case is something that can be addressed by the final token exchange spec. In OAuth and Connect we have three entities that receive tokens. 1, User agents: code, token, id_token (any of them might be PoP using token binding) 2, Clients: code (pop via PKCE) Refresh tokens (pop via Token binding?), access tokens (pop via the OAuth POP spec) , id_tokens (token binding via browser) , jwt or other assertions (?) 3 Resource Server: Access tokens ( these might be bound to the Audience of the token for exchange) To the original question. The client might use dynamic client registration, or it might use PKCE. In the PKCE case if the AT a POP token and the client uses it’s POP key to prove it it’s identity then it should be able to introspect the token. Though from a spec point of view there are admittedly still some gaps in doing that at the moment. John B. On Jul 19, 2015, at 7:00 AM, Mike Jones michael.jo...@microsoft.com wrote: As a note for the upcoming Token Exchange discussion in Prague, I’ll note that this same question may apply there. Specifically, can the party requesting the exchange be a public client? (And does it have to be an OAuth client at all?) Cheers, -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Aaron Parecki Sent: Sunday, July 19, 2015 6:31 AM To: OAuth WG Subject: [OAUTH-WG] Token introspection for public clients? The introspection draft states that the introspection endpoint MUST require authentication of clients. It mentions either client authentication (id+secret) or a separate bearer token. How are public clients expected to use the token introspection endpoint? I didn't see a note in the document about that at all. Aaron Parecki aaronparecki.com https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2faaronparecki.comdata=01%7c01%7cMichael.Jones%40microsoft.com%7cf827a8f80a39419ba5e208d28ff2ce12%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=OLWwlvUWyXz2HZaGyASvAlZ9fEhJt6a7A3%2bdfdgUdUY%3d @aaronpk https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftwitter.com%2faaronpkdata=01%7c01%7cMichael.Jones%40microsoft.com%7cf827a8f80a39419ba5e208d28ff2ce12%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=U7RXStYZ1HIL%2bTlM99%2fYW8W9RPw8bTgHgXcjuvyK0t0%3d ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token introspection for public clients?
How are public clients supposed to authenticate if there is no secret? Isn't fishing for valid tokens just as much of an issue at the resource server? I don't see how having the introspection endpoint require client authentication actually solves the fishing problem since attackers could just fish against the resource server. In fact, if the resource server queries the introspection endpoint to check if tokens are valid, then that effectively gives an attacker a way to fish for tokens using the resource server's credentials. --- Aaron Parecki http://aaronparecki.com On Sat, Jul 18, 2015 at 10:04 PM Justin Richer jric...@mit.edu wrote: Public clients can use the token-based auth mechanism, can’t they? If you don’t have some form of authentication on the introspection endpoint, you end up with a way for people to anonymously and programmatically fish for valid token values. — Justin On Jul 19, 2015, at 6:30 AM, Aaron Parecki aa...@parecki.com wrote: The introspection draft states that the introspection endpoint MUST require authentication of clients. It mentions either client authentication (id+secret) or a separate bearer token. How are public clients expected to use the token introspection endpoint? I didn't see a note in the document about that at all. Aaron Parecki aaronparecki.com @aaronpk http://twitter.com/aaronpk ___ 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] Token introspection for public clients?
In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because clients shouldn’t be doing the introspection in the first place — the whole spec is there to support resource servers introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result came back — you could easily give a suspected attacker valid-looking-but-fake data as one mitigation mechanism.) The introspection response can give you information about where else the token could be used, potentially. Additionally, the RS really ought to be preventing data-fishing attacks like this just for its own sake anyway. There are lots of techniques for doing this, but they tend to be specific to the kind of API that’s being served. Requiring the resource server to authenticate with the authorization server also allows you to do a few other useful things. Our implementation, for example, limits the token information that is returned to a particular AS. This allows us to have tokens that can be used in multiple RS’s without those RS’s ever even knowing the token is powerful enough to be used elsewhere. It prevents information about the authorization from leaking to parties who have no business knowing. Hope this helps clarify it, — Justin On Jul 19, 2015, at 7:59 PM, Aaron Parecki aa...@parecki.com wrote: How are public clients supposed to authenticate if there is no secret? Isn't fishing for valid tokens just as much of an issue at the resource server? I don't see how having the introspection endpoint require client authentication actually solves the fishing problem since attackers could just fish against the resource server. In fact, if the resource server queries the introspection endpoint to check if tokens are valid, then that effectively gives an attacker a way to fish for tokens using the resource server's credentials. --- Aaron Parecki http://aaronparecki.com http://aaronparecki.com/ On Sat, Jul 18, 2015 at 10:04 PM Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: Public clients can use the token-based auth mechanism, can’t they? If you don’t have some form of authentication on the introspection endpoint, you end up with a way for people to anonymously and programmatically fish for valid token values. — Justin On Jul 19, 2015, at 6:30 AM, Aaron Parecki aa...@parecki.com mailto:aa...@parecki.com wrote: The introspection draft states that the introspection endpoint MUST require authentication of clients. It mentions either client authentication (id+secret) or a separate bearer token. How are public clients expected to use the token introspection endpoint? I didn't see a note in the document about that at all. Aaron Parecki aaronparecki.com http://aaronparecki.com/ @aaronpk http://twitter.com/aaronpk ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token introspection for public clients?
Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because clients shouldn’t be doing the introspection in the first place — the whole spec is there to support resource servers introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result came back — you could easily give a suspected attacker valid-looking-but-fake data as one mitigation mechanism.) The introspection response can give you information about where else the token could be used, potentially. Additionally, the RS really ought to be preventing data-fishing attacks like this just for its own sake anyway. There are lots of techniques for doing this, but they tend to be specific to the kind of API that’s being served. Requiring the resource server to authenticate with the authorization server also allows you to do a few other useful things. Our implementation, for example, limits the token information that is returned to a particular AS. This allows us to have tokens that can be used in multiple RS’s without those RS’s ever even knowing the token is powerful enough to be used elsewhere. It prevents information about the authorization from leaking to parties who have no business knowing. Hope this helps clarify it, — Justin On Jul 19, 2015, at 7:59 PM, Aaron Parecki aa...@parecki.com mailto:aa...@parecki.com wrote: How are public clients supposed to authenticate if there is no secret? Isn't fishing for valid tokens just as much of an issue at the resource server? I don't see how
Re: [OAUTH-WG] Token introspection for public clients?
I totally agree with that - and that’s how we gonna implement it in identity server. We are planning to introduce something called a “scope secret” - it’s like a client secret but for resources. — cheers Dominick Baier On 20 Jul 2015 at 07:01:48, Justin Richer (jric...@mit.edu) wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because clients shouldn’t be doing the introspection in the first place — the whole spec is there to support resource servers introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result came back — you could easily give a suspected attacker valid-looking-but-fake data as one mitigation mechanism.) The introspection response can give you information about where else the token could be used, potentially. Additionally, the RS really ought to be preventing data-fishing attacks like this just for its own sake anyway. There are lots of techniques for doing this, but they tend to be specific to the kind of API that’s being served. Requiring the resource server to authenticate with the authorization server also allows you to do a few other useful things. Our implementation, for example, limits the token information that is returned to a particular AS. This allows us to have tokens that can be used in multiple RS’s without those RS’s ever even knowing the token is powerful enough to be used elsewhere. It prevents information about the authorization from leaking to parties who have no business knowing. Hope this helps clarify it, — Justin On Jul 19, 2015, at 7:59 PM, Aaron Parecki aa...@parecki.com wrote: How
Re: [OAUTH-WG] Token introspection for public clients?
Public clients can use the token-based auth mechanism, can’t they? If you don’t have some form of authentication on the introspection endpoint, you end up with a way for people to anonymously and programmatically fish for valid token values. — Justin On Jul 19, 2015, at 6:30 AM, Aaron Parecki aa...@parecki.com wrote: The introspection draft states that the introspection endpoint MUST require authentication of clients. It mentions either client authentication (id+secret) or a separate bearer token. How are public clients expected to use the token introspection endpoint? I didn't see a note in the document about that at all. Aaron Parecki aaronparecki.com http://aaronparecki.com/ @aaronpk http://twitter.com/aaronpk ___ 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
