[Openid-specs-ab] Questions about third party initiated login
Michael.Jones at microsoft.com
Wed Jun 11 19:58:24 UTC 2014
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.
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
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. :)
"Education is the path from cocky ignorance to miserable uncertainty." - Mark Twain
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab