I'm trying to authorize my standalone application. But after I click "Allow" it always redirects to http://oauth.vk.com/error?err=2 and gives this as response body:
{"error":"invalid_request", "error_description":"Security Error"}
Here's the request URL (I do have correct client_id):
https://oauth.vk.com/authorize?client_id=...&scope=messages,offline&redirect_uri=https://oauth.vk.com/blank.html&display=page&v=5.37&response_type=token
It seems that I've tried everything:
Turning application on and off
Passing scope as bit mask
URI encoding some parameters to have correct URL
and so on
After hour of searches I've found this.
So, it means that user has an old session and must re-login in browser.
Space in state parameter causes this.
OAuth 2 RFC, sections 4.1.1 on authorization request and 4.1.2 on authorization response, recommends using state parameter to maintain state in authorization code flow, particularly to prevent CSRF.
When I set this field to CSRFTOKEN123 http://my.site/next/url, I got this error. Replacing (space) with : to get CSRFTOKEN123:http://my.site/next/url helps.
By the way, I couldn't find any mention of state parameter on VK documentation website but VK OAuth 2 authorization system actually supports it. It couldn't be called OAuth 2 otherwise. So I find it legit to use state parameter.
The topic https://vk.com/topic-17680044_30635058 mentioned by author is closed now, current discussion is https://vk.com/topic-1_24428376. There are number of questions on this. All in Russian.
Related
Question: What is the difference between the following OAuth 2.0 authorization URLs:
In various documents example I see reference to this authorization URL:
https://accounts.google.com/o/oauth2/auth
In other documents example I see reference to this authorization URL:
https://accounts.google.com/o/oauth2/v2/auth
These URLs are used for code like this (Python):
authorization_base_url is one of the above URLs.
authorization_url, state = gcp.authorization_url(
authorization_base_url,
access_type="offline",
prompt="select_account",
include_granted_scopes='true')
I am in the process of debugging another Google OAuth 2.0 Refresh Token problem and I am trying to clarify the exact solution link. I am seeing behaviour that does not match documentation.
There's no documentation of the differences but in general they are different versions of the same endpoint.
A newer version may introduce improved or changed behavior though protocol-wise and interoperability-wise there should be no difference to the consumer. They're all OAuth 2.0/OIDC compliant but within the spec there are different optional behaviours that may be implemented.
As an example of that: when an error occurs on the Google side, Google may decide to stop the flow and show this error to the user, or alternatively return an error to the Client as OAuth 2.0 allows you to do. Both are valid behaviors and different versions of the Authorization endpoint may implement a different flavor.
I have done quite a intensive research on repeated redirects (For e.g link ) but my problem is a bit different. Hence reaching out to you guys for help.
Let's say, my Sign on URL is - https://localhost/URL
and my redirect URL is https://localhost/url, this ends up in infinite loop throwing an IDX10311 exception. Am I missing any trick to ignore Case sensitivity validation between sign-on and redirect URL?
P.S: Signing on with https://localhost/url, works like a charm
URI comparison are usually done using simple String comparison. According to Uniform Resource Identifier rfc (rfc3986), comparison is usually done character to character between tow URIs. This can be found under section 6.2.1 of the standard.
As per OpenID Connect, one must use exact value used at the registration for redirect_uri value of the request. So as I can see you are getting an erro response from your identity provider for this specific reson. More can be found from the OAuth2.0 specification's section 4.1.2.1 - RFC6749.
In your implementation, you must validate for proper error messages from your identity provider
In the code below:
https://github.com/jeyben/IOSLinkedInAPI/blob/master/IOSLinkedInAPI/LIALinkedInAuthorizationViewController.m
On lines 108-109, the author checks to see if the state parameter returned after the Oauth2.0 authentication is the same as the one passed in. Is that necessary? How would the state parameter change or be compromised in a webview?
RECOMMENDED. An opaque value used by the client to maintain
state between the request and callback. The authorization
server includes this value when redirecting the user-agent back
to the client. The parameter SHOULD be used for preventing
cross-site request forgery as described in Section 10.12.
From https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1
However that said I do not think it is absolutely necessary as it would be a stretch for someone to try and do cross-site forgery due to the SSH provided by default from the OAuth 2.0 protocol. It is still a good security measure to take though as it is possible for someone to learn the way the requests are made, or a portion of them and try to fake things out. Also it is interesting how this changed on mobile but quite honestly it does not change all that much. Something that is important about the state being checked is that if the user was on a website that was hacked in the WebView then the mobile application could use that state to protect itself from accepting the hacked websites information as true. Anyways this is one of the many conversations that could be had about the state variable.
Hope this helps.
Anthony
I'm Using OAuth2 with Doorkeeper to protect my API.
The problem is that one client had several different flows in which he redirects users to my OAuth flow.
He would like to dynamically add some parameters when redirecting the user to my OAuth flow and get these parameters back when I'm calling his callback URL. This way he will be able to tell from which flow this callback originated.
Is this possible with OAuth 2? with Doorkeeper? How?
Edit:
Thanks Zólyomi István for your hint.
I set the state parameter before calling the auth endpoint and got it back in the callback. However, I found that I get back a state parameter with some apparently random string even if I don't set anything. Any idea what it is? I'd like to be sure I'm not messing up anything...
Well, using the state parameter was indeed the solution. Just adding state to the request and then getting it back when the control is returned to my code.
According to the specification:
The state parameter is used to link requests and callbacks to prevent
CSRF attacks where an attacker authorizes access to his own resources
and then tricks a users into following a edirect with the attacker's
token.
Apparently ominauth oauth 2 assigns random value to this parameter unless it's used in order to detect CSRF attacks.
I've read all the threads about simiular issues on SO and elsewhere, and none of them have solved my problem.
I'm using Twython as a wrapper around the API. I've tried setting oauth_callback EVERYWHERE. Using the internal mechanism in Tython (which is done by setting callback_url on instantiation), by manually modifying the auth_url and appending the argument by before redirecting the user, etc. I've tried deleting and recreating both new twitter apps and new twitter accounts, to no avail.
Whenever I redirect the client to twitter, the correct oauth_callback is ALWAYS visible in the url along with the oauth_token, but the api always ignores this argument and overrides it with the url in the settings of my twitter app (both are under the same domain). I have tried figuring this out for several hours and I'm at a dead end. I've seen this work before and I've done it plenty of times, so I don't know what could possible be going wrong.
It's strange-- even if i set the callback to 'oob', which ought to trigger the PIN workflow rather than a callback, this argument is EVEN THEN ignored. Any ideas why?
You specify the oauth_callback value when you get a request token as specified in OAuth 1.0a. In 1.0 it you could pass it along with with the user when they go to twitter.com but was changed for security reasons. You can read more about it in the /oauth/request_token docs.