Determine user id in oauth callback_问答_开发者

The OAuth process is:

For OAuth authentication, the app (a.k.a OAuth client) redirects the user to the authorize_url
This redirects the user to oauth ser开发者_StackOverflowver's webserver, where the user grants the web app access to his/her account
OAuth server redirects the user to the callback url provided by the application (a.k.a oauth client). At this point, the callback came from the OAuth server and hence does not have the session id or session hash. How is the application to determine which user the post-oauth callback is being called for?

I though the way this works is:

When you redirect user to the authorize_url you append certain parameters to the query string ?id=xxx
When the OAuth server redirects to the callback_url provided by the client, one of the parameters with the HTTP message will be the parameter appended to the query string in step 1.

However, this does not seem to work for the OAuth server I am trying to hook into.

Any suggestions?

After the user has verified your request token (by entering username and password) you should get the oauth_token and oauth_verifier parameters sent back, appended to the callback.

If this works, but other parameters you specified in the callback are NOT included in the callback, then it may be the case that the provider simply ignores the oauth_callback you are sending in the request token step.

If this is the case, the provider will refer to predefined callback, usually one that you specified when acquiring consumer key and secret.

OAuth providers are allowed to ignore callbacks sent during the authorization flow (except for signing purposes). Some providers do this to add an extra layer of security.

You can use state parameter for that, also the auth server have to provide user details service based on only access token.

What do you mean by "this does not work"?

The server does not send the query part back? You must encode the state in the callback url you provide to the oauth server. This can be done in the query or in the path part. I see no reason why this is not working?

Maybe you assume that you have a single, generic callback that gets expanded with state automatically? As far is a know this is not the case.

EDIT

I re-read the docs at Google's implementation:

You can specify a value for oauth_callback in an OAuthGetRequestToken request, 
to determine where Google redirects the user after they authorize your access 
request. The callback URL can include query parameters. The redirect will include 
the same query parameters, as well as the authorized request token, which your
application must be able to parse.

For example, when supporting multiple languages, you can include 
a query parameter that identifies the version of the application that a user is
viewing. An oauth_callback value of "http://www.yoursite.com/Retrievetoken?Lang=de"
would result in the redirect 
"http://www.yoursite.com/Retrievetoken?Lang=de&oauth_token=DQAADKEDE". 
Parsing the token and the language parameter ensures that the user is 
redirected back to the correct version of the site.

SO (in contradiction to my statement above) the OAuth server actively appends information (&oauth_token=kkk) to your URL. THe token should be the same you received as result from "OAuthGetRequestTOken". THis does not work for you?

As far as i understand now the server should literally copy everything you have in the callback_url and add the token you received from the service call

Do you have a log of what exactly your OAuth server calls? Who is the service provider? I can't imagine that he's missing this feature...

I cannot see the reason that you'd like to send ID from OAuth Provider to OAuth Consumer. Can you explain a little bit more why you need to do this?

If you have session cookie associated with your users, you will know which user is coming back to you (after redirect), because you can have a session with him - he will be redirected through the browser and return your cookie.

Even if the OAuthProvider send you its internal user-id (which is unnecessary and very unlikely I think), what are you going to do with it - it will not match your internal web site user id, it's totally different user-id for the provider site... or maybe I cannot get your question very well....

Best regards