[Openid-specs-ab] Questions about third party initiated login

[John Bradley]

The best general advice is to not allow target uri unless you have a site specific way to verify them, and to never redirect to them on a failed login.  That goes for target uri encoded in state or 3rd party ones. 

The largest problem is a RP that redirects on error based on the contents of state. 

Sent from my iPhone

> On Jun 15, 2014, at 7:34 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
> I noticed that, even in the OP-initiated case (which is a special case of the general 3rd party-initiated case), we don’t define any discovery parameters that the OP can use to declare a legal list of target_link_uri  values.  (This would be somewhat similar in purpose to the list of redirect_uris that a client declares in its registration.)  Should we have done that?
>  
> In your note below, I don’t see any general-purpose mechanism that RPs could commit to code to prevent open redirection via the target_link_uri  when general 3rd party-initiated login is used.  Am I missing something, or are we missing something in this regard in the specs?
>  
>                                                             Thanks,
>                                                             -- Mike
>  
> From: John Bradley [mailto:ve7jtb at ve7jtb.com] 
> Sent: Friday, June 13, 2014 3:58 PM
> To: Mike Jones
> Cc: Roland Hedberg; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Questions about third party initiated login
>  
> The redirect URI needs to be checked that it is inside the domain that the Client is willing to redirect to.   Typically this is some known landing page or deep link.
>  
> This sort of functionality is similar to Shibboleth target or SAML 2.0  RelayState in IdP-Initiated SSO.
>  
> After a successful authentication The client needs to create a session and redirect the user agent to the target_link_uri. 
>  
> Typically a Client might use state to store the target_link_uri in the Authorization request.  
> Clients that support his also need to preform some sort of sanity check on the target_link_uri, and never redirect without a positive authentication response.
> An attacker can always modify state as it is not signed in the request.  Generating a forged failed response can trick some SP/Clients into redirecting and that needs to be blocked.
>  
> That was one of the reasons I created. http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state
> As a way that a Client can prevent tampering with the target_uri (now that I think about it,  target_link_uri might be a better name to be consistent with Connect)
>  
> It may be that using signed state directly from the IdP may be a simpler solution to the problem of IdP initiated login saving a number of round trips for the most common case.
>  
> For 3rd party the way we have it in the spec with the 3rd party initiating the flow at the client and the client being responsible for protecting the user and itself from forged authentication requests.
>  
> John B.
>  
>  
>  
> On Jun 11, 2014, at 3:58 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
> 
> Hi Roland.  My replies are inline.  I’ve cc’ed the mailing list to allow others to comment on my responses – especially the response about verifying the target_link_uri value to prevent it from being an open redirector, which I’d like to hear other’s thoughts on.
>  
> -----Original Message-----
> From: Roland Hedberg [mailto:roland.hedberg at adm.umu.se] 
> Sent: Tuesday, June 10, 2014 11:03 PM
> To: Mike Jones
> Subject: Re: Notes from our interop conversation
>  
> Hi Mike,
>  
> looked some more at the third party (OP) initiated login.
>  
> A couple of questions:
>  
> - target_link_uri redirect to after authentication.
>  
> does that mean that no access token request are performed by the RP, just the authentication/authorization request.
> Sounds reasonable since this is only about authentication, right ?
>  
> There’s intentionally nothing special about the authentication behavior when the RP sends an authentication request after receiving a third party initiated login request.  The OP should do whatever it normally does, given the request parameters used (such as the response_type, the scope values, the “claims” values, etc.).  That will include returning an access token for most response_type values.  Also, the RP is free to use the access token to obtain claims from the UserInfo endpoint, if it desires, before redirecting to the target_link_uri location.
>  
> - the RP MUST verify the target_link_uri. What does this mean ?
>  
> That’s a REALLY GOOD QUESTION.  I don’t know what check the RP should apply to the target_link_uri value to prevent it from being used as an open redirector.  My first instinct was that it should check it against a list of values provided by the OP in its discovery document, but there are no such values defined, and in fact, the initiator doesn’t have to be an OP.  John, you wrote this language, I believe.  What did you have in mind here?
>  
> When the user is redirected back to the target_link_uri is there anything attached to that, like an id_token.
>  
> No
>  
> What are the error messages if any ?
>  
> No extra ones are defined.  Given that the authentication requests/responses are the normal ones, no additional errors are needed for those.  The redirects either succeed or fail, with normal browser errors happening on failure.
>  
> And finally, if RPs support third party login that could actually be used to test some of the RPs functionality.
> I could use the login_hint to carry testing information. Sneaky I know but .. :-)
>  
> Good idea. J
>  
> -- Roland
> "Education is the path from cocky ignorance to miserable uncertainty.” - Mark Twain
>  
>                                                                 -- Mike
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140615/66fc3479/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2734 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140615/66fc3479/attachment.p7s>