Security Token Service (STS) Sorry it is WS-* speak http://en.wikipedia.org/wiki/Security_token_service
You can emulate some of it with the assertions extension. The WG has a document as a starting position for a more general approach. https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 Brian Campbell and I also documented our take on it for discussion. https://tools.ietf.org/html/draft-campbell-oauth-sts-01 At the moment they don't really take into account issuing PoP tokens in exchange but I expect that would be added as a WG document progresses. It is on the WG to do list. John B. > On Mar 17, 2015, at 8:01 PM, Bill Mills <[email protected]> wrote: > > STS? > > > > On Tuesday, March 17, 2015 2:40 PM, John Bradley <[email protected]> wrote: > > > This is fun:) > > I might ask what part of a OAuth 1.0a token is the user credential. That is > a slippery idea in itself. The token is a reference to some notion of > identity (in some cases) that needs to be dereferenced anyway. > > So in the same way a POP JWT access token in OAuth 2 that may indeed contain > claims about the subject would need to be exchanged at a AS for a new token > containing claims about the subject and the new presenter, or depending on > the security model it could be included directly in a new self signed AT. > > From a enterprise policy point of view having a REST like STS functionality > is I think the right long term answer. > > John B. > > > >> On Mar 17, 2015, at 6:32 PM, Bill Mills <[email protected] >> <mailto:[email protected]>> wrote: >> >> In practice one of the drawbacks of the Oauth 1.0a tokens was that they were >> not proxyable and so a connection to the edge then means you have to unwrap >> that and make a new internal token to be usedwhich isn't as good as the >> actual user credential. >> >> >> >> On Tuesday, March 17, 2015 2:26 PM, John Bradley <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> PoP tokens need to be presented with a proof the presenter knows the secret. >> That is the same principal as in OAuth 1.0a with needing to show knowledge >> of the "token secret". >> >> I don't know what you mean by proxies internally. If the RS needs another >> token to access a resource it should use the assertion flow and authenticate >> itself to get another token based on the access token. >> Passing around a PoP token as a bearer token is insecure/bad. >> >> In OAuth 1.0a because of the tight relationship between the "Service >> Provider" and the "Protected Resource" people would be less likely to try it >> but because the protected resource knows the "token secret" it could still >> do lots of unexpected bad things. >> >> Proxying access tokens is not something RS should do, they need to be >> exchanged at a AS for a new AT with the correct rights and optionally >> binding it to a new PoP key. >> >> John B. >> >> >> >> On Mar 17, 2015, at 6:14 PM, Bill Mills <[email protected] >> <mailto:[email protected]>> wrote: >>> >>> Yes. There's still the open question of whether/how PoP tokens can be >>> proxied internally within a site though. If they can be proxied then it >>> goes back to unsolved. >>> >>> >>> >>> On Tuesday, March 17, 2015 2:12 PM, John Bradley <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> Or by OAuth 2 PoP. >>> >>> >>>> On Mar 17, 2015, at 6:00 PM, Bill Mills <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> "Yes but it is custom. People are inventing structured scopes like >>>> "aud:https://foo.com <http://foo.com/>", and that potentially doesn't >>>> solve the security issue if a client just passes on the scopes it receives >>>> in the error response, the bad RS just adds a scope for the good RS." >>>> >>>> This isn't solved by "aud", it is solved by OAuth 1.0a though.... >>>> >>>> >>>> >>>> >>>> On Tuesday, March 17, 2015 1:54 PM, John Bradley <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> Yes but it is custom. People are inventing structured scopes like >>>> "aud:https://foo.com <http://foo.com/>", and that potentially doesn't >>>> solve the security issue if a client just passes on the scopes it receives >>>> in the error response, the bad RS just adds a scope for the good RS. >>>> >>>> The client then potentially needs to understand the custom structures >>>> scopes of every AS it might deal with. >>>> >>>> I think that would lead to lots of problems trying to make that a pattern >>>> long term. At teh moment yes you can do it with a scope as long as the >>>> client and AS both understand what is going on. >>>> >>>> >>>> We added "aud" as a separate parameter for PoP as the token format for >>>> different RS might be different as well as the symmetric pop keys needing >>>> to be encrypted with different keys. >>>> Yes we could have invented a special scope to carry the audience but a >>>> separate parameter was much cleaner. >>>> >>>> I know some people have started using "aud" as a way to communicate the >>>> resource when a scope applies to multiple RS but they may take different >>>> token formats JWT vs opaque etc. >>>> >>>> Brian commented that the "aud" parameter may be useful beyond PoP so we >>>> might want to think about documenting it in it's own mini spec, if I >>>> understood him correctly. >>>> >>>> I think that may not be a bad idea as we are also planning on using it in >>>> NAPPS. >>>> >>>> John B. >>>> >>>>> On Mar 17, 2015, at 5:39 PM, Bill Mills <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> I don't think it's "overloading scope names" to use them that way. The >>>>> aud value(s) could as easily be carried in scope as anywhere. Nothing >>>>> says a scope can't be "https://foo.com <https://foo.com/>", and that >>>>> Foo.com <http://foo.com/> requires that scope to be present for a token >>>>> to be accepted. I would not make it foo.com <http://foo.com/>-read-mail >>>>> for example. >>>>> >>>>> If it's more convenient to put it in aud I can accept that, but it's the >>>>> same functionality and can be implemented in scopes now. >>>>> >>>>> >>>>> >>>>> On Tuesday, March 17, 2015 12:41 PM, John Bradley <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> People have been overloading scope names to create implicit audience. >>>>> >>>>> The problem is that clients need to know via some magic method that you >>>>> need to ask for scope "purple" to get write access to RS 2. >>>>> >>>>> Having an explicit "aud" parameter gives clients a way to communicate to >>>>> the AS what RS they are asking for a token for. >>>>> >>>>> the security issue is that if a client discovers a API out via some out >>>>> of band mechanism the OAuth error code can tell the client go to AS X and >>>>> ask for Scope Y. >>>>> >>>>> Unfortunately without POP tokens or at-least passing the URI of the RS to >>>>> the AS via "aud", a bad RS could get a legitimate client to give it a >>>>> token that can be replayed at a legitimate RS. >>>>> >>>>> This was one of the issues that Eran Hammer-Lahav was particularly >>>>> concerned about. >>>>> >>>>> I think I proposed a "aud" parameter to the token endpoint back then as a >>>>> alternative to requiring HMAC tokens, but that got lost in the confusion >>>>> at the time. >>>>> >>>>> At that time though people were not yet thinking about interoperable >>>>> OAuth API, only relatively tightly bound clients that were preconfigured >>>>> for the API endpoints they were using. >>>>> >>>>> In Health and other places we are starting to see standard clients that >>>>> discover API endpoints and configure themselves based on a users Identity >>>>> to use a arbitrary OAuth AS, moving into federation of AT. >>>>> >>>>> That is one of the reasons POP will be important, as it prevents RS from >>>>> misusing federated tokens by presenting them at other RS. >>>>> >>>>> The simplest thing to do is have the client say what RS it is trying to >>>>> access explicitly (The "aud" parameter), and including an audience in the >>>>> AT. to protect against malicious RS. >>>>> >>>>> PoP is the step up that also protects against tokens being intercepted >>>>> and replayed by another client. >>>>> >>>>> John B. >>>>> >>>>>> On Mar 17, 2015, at 4:10 PM, Bill Mills <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> This may have been hashed out already and I missed it, but "aud" just >>>>>> becomes another kind of scope, correct? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tuesday, March 17, 2015 8:50 AM, John Bradley <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> >>>>>> You could do that, but it is probably safer for the AS to know what RS >>>>>> it can issue tokens for and refuse to issue a token for RS A to a client >>>>>> asking for a token with RS X as the aud. >>>>>> >>>>>> John B. >>>>>>> On Mar 16, 2015, at 8:27 PM, Dixie Baker <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>> >>>>>> The threat that RFC6819 4.6.4 describes is when a client obtains an AT >>>>>> and then sends it to a counterfeit RS, which then uses the AT to access >>>>>> resources from a legitimate RS, on the end-user's behalf. >>>>>> >>>>>> The suggested countermeasure is a bit difficult to interpret: >>>>>> "Associate the endpoint URL of the resource server the client talked to >>>>>> with the access token (e.g., in an audience field) and validate the >>>>>> association at a legitimate resource server. The endpoint URL >>>>>> validation policy may be strict (exact match) or more relaxed (e.g., >>>>>> same host). This would require telling the authorization server about >>>>>> the resource server endpoint URL in the authorization process." >>>>>> >>>>>> As I read this, the suggestion is to have the client pass the URL of the >>>>>> bad RS in the request to the AS (using the audience field). The AS then >>>>>> would include that RS URL in the AT. Then, when the client passes the >>>>>> AT to the bad RS, and it passes it on to the good RS, the good RS will >>>>>> check the audience field, compare that URL with its own, and refuse the >>>>>> request. >>>>>> >>>>>> -Dixie >>>>>> >>>>>> >>>>>> >>>>>> Dixie B. Baker, Ph.D. >>>>>> Senior Partner >>>>>> Martin, Blanck and Associates >>>>>> Office (Redondo Beach, CA): 310-791-9671 >>>>>> Mobile: 310-279-2579 >>>>>> >>>>>> On Mar 16, 2015, at 11:39 AM, John Bradley <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> >>>>>> Brian and I were talking about "aud" used as a parameter to the token >>>>>> endpoint when using a code or refresh token to indicate what RS the >>>>>> resulting AT will be used at. >>>>>> >>>>>> Sending a audience in the AT wouldn't help prevent the attack being >>>>>> discussed, though it may stop other sorts of attacks if the RS can tell >>>>>> if a AT was issued for it or another RS. >>>>>> >>>>>> In PoP having the AS check that you are sending the AT to the correct RS >>>>>> is less important as the AT if stolen can't be used to replay against >>>>>> the real AS. >>>>>> >>>>>> Though depending on the app the bogus RS feeding the app the wrong info >>>>>> may well be a problem as well. >>>>>> >>>>>> John B. >>>>>> >>>>>>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt >>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>> >>>>>> >>>>>> I don't think putting an aud into an AT will help to prevent counterfeit >>>>>> RSs (as long as the aud is nit directly derived from the original URL >>>>>> used by the client to invoke the counterfeit RS. as long as the aud is a >>>>>> symbolic name of any kind, the counterfeit RS will accept ATs for the >>>>>> legitimate RS and just (ab)use it. >>>>>> >>>>>> POP on the contrary helps since the counterfeit RS, in order to send a >>>>>> message to the legitimate RS, needs to produce a new digitally signed >>>>>> message using the correct secret, which it doesn't know. >>>>>> >>>>>> kind regards, >>>>>> Torsten. >>>>>> >>>>>> >>>>>> >>>>>> Am 16.03.2015 um 17:40 schrieb Dixie Baker >>>>>> <[email protected] <mailto:[email protected]>>: >>>>>> >>>>>> >>>>>> Using the "aud" parameter makes sense to me. Good suggestion. >>>>>> >>>>>> Authenticating the client to the RS would not address the counterfeit RS >>>>>> threat. >>>>>> >>>>>> -Dixie >>>>>> >>>>>> >>>>>> Dixie B. Baker, Ph.D. >>>>>> Senior Partner >>>>>> Martin, Blanck and Associates >>>>>> Office (Redondo Beach, CA): 310-791-9671 >>>>>> Mobile: 310-279-2579 >>>>>> >>>>>> On Mar 16, 2015, at 6:43 AM, Brian Campbell <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to help >>>>>>> identify the RS to whom the AT should be issued. It is useful but it's >>>>>>> mostly about getting format/content/etc of the AT correct for the RS >>>>>>> rather than it is about preventing possible AT leaks. >>>>>>> >>>>>>> I do think an "aud(iance)" parameter at both token and authorization >>>>>>> endpoints would have utility beyond the POP work. So defining it >>>>>>> independently might make sense. >>>>>>> >>>>>>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> In POP key distribution we do introduce a "audiance" parameter to the >>>>>>> token_endpoint. >>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1 >>>>>>> >>>>>>> <https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1> >>>>>>> >>>>>>> It would be possible to have a small spec to define using "aud" with >>>>>>> bearer tokens, however that would be undefined behaviour at this point. >>>>>>> >>>>>>> I don't know of any clients that would try to access a RS server and >>>>>>> then besed on the error response try and get a access token from the AS >>>>>>> specified in the error. >>>>>>> >>>>>>> In POP we are trying to both protect agains that attack and more common >>>>>>> ones like doing a MiM to intercept the AT or the RS being hacked and >>>>>>> leaking the token. >>>>>>> >>>>>>> Using "aud" with bearer tokens would be useful, but probably won't stop >>>>>>> the majority of possible AT leaks. >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> >>>>>>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt >>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> Hi Josh, >>>>>>>> >>>>>>>> I'm not aware of a common practice to use such a parameter. The WG is >>>>>>>> instead heading towards authenticated requests to the resource server >>>>>>>> (see https://tools.ietf.org/html/rfc6819#section-5.4.2 >>>>>>>> <https://tools.ietf.org/html/rfc6819#section-5.4.2>). >>>>>>>> >>>>>>>> Please take a look onto >>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture >>>>>>>> <http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture> and >>>>>>>> further drafts on this topic. >>>>>>>> >>>>>>>> kind regards, >>>>>>>> Torsten. >>>>>>>> >>>>>>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit >>>>>>>>> Resource Server"), RFC6819 describes a threat where a counterfeit >>>>>>>>> resource server tricks a client into obtaining and sharing an access >>>>>>>>> token from a legitimate authorization server. One of the proposed >>>>>>>>> mitigations involves: "telling the authorization server about the >>>>>>>>> resource server endpoint URL in the authorization process." >>>>>>>>> >>>>>>>>> In other words, this mitigation would ask the client to pass an >>>>>>>>> additional parameter when redirecting to the Authorization server's >>>>>>>>> "authorize" URL, effectively something like: >>>>>>>>> >>>>>>>>> https://auth-server/authorize <https://auth-server/authorize>? >>>>>>>>> response_type=code& >>>>>>>>> client_id=123& >>>>>>>>> state=456& >>>>>>>>> scope=read-all& >>>>>>>>> redirect_uri=https://app-server/after-auth&; >>>>>>>>> <https://app-server/after-auth&;> >>>>>>>>> resource_server_that_told_me_to_authorize_here=https://attacker.com >>>>>>>>> <https://attacker.com/> >>>>>>>>> >>>>>>>>> (And if the authorization server saw a value it didn't like in the >>>>>>>>> final parameter, it would reject the request.) >>>>>>>>> >>>>>>>>> This is obviously not appropriate in every authorization scenario, >>>>>>>>> but it is useful anytime there's a discovery process by which apps >>>>>>>>> learn about authorization servers from resource servers. Since it's >>>>>>>>> something of a common need, I wanted to see if there was any common >>>>>>>>> practice in how to name this parameter, or whether it's worth >>>>>>>>> registering a standard extension at >>>>>>>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml >>>>>>>>> >>>>>>>>> <http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml> >>>>>>>>> . (I don't see one there now -- possibly I'm just missing it.) >>>>>>>>> >>>>>>>>> If so, what should it be called? The name I used in the example above >>>>>>>>> is a bit verbose :-) >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Josh >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
