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

Justin Richer jricher at MIT.EDU
Mon Jun 16 00:11:00 UTC 2014 

I think it's going to be so specific to each RP that there's nothing we 
can codify in the spec that will be universal enough to work. We 
probably should have had more guidance as to what good checking 
mechanisms could be. Off the top of my head:

  1) Strict full-string matching of whitelisted URLs at the RP
  2) Strict prefix matching based on RP's root (good for single-site 
logins, for instance)
  3) Domain-based matching (good for clustered applications, where the 
"login" gateway box might be one of many hosts)
  4) Regex or other pattern based matching

All of these have to be checked by the RP, not the OP, so unless we want 
to pick one and only one of those cases we can't have the OP checking 
for all possible RPs as well.

  -- Justin


On 6/15/2014 7:34 PM, Mike Jones wrote:
>
> I noticed that, even in the OP-initiated case (which is a special case 
> of the general 3^rd party-initiated case), we don't define any 
> discovery parameters that the OP can use to declare a legal list of 
> target_link_urivalues.  (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_uriwhen general 3^rd 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 
> <mailto: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 thetarget_link_urivalue 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 
> thetarget_link_urilocation.
>
> - 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 thetarget_link_urivalue 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 <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> 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/4e6ca920/attachment.html>

More information about the Openid-specs-ab mailing list