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

Mike Jones Michael.Jones at microsoft.com
Sun Jun 15 23:34:41 UTC 2014

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?

                                                            -- 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 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.


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. :)

-- 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140615/bb154a78/attachment-0001.html>

More information about the Openid-specs-ab mailing list