We integrate with YAMMER using OAuth2.0 Server-side flow.
Some of our clients have subdomains so our redirect URI has to be dynamic. We set up the yammer-app to have a dynamic redirect URI as specified in the documentation. Our redirect URI looks like this:
https://example.com
Problem:
It works not every time! Some redirects to the YAMMER user authentication page are getting this error:
invalid redirect_uri
The URL looks like this:
https://www.yammer.com/dialog/oauth?client_id=XXX&redirect_uri=http://www.examle.com/yammer/callback
The error only happens some times so it is hard to reproduce or trace the reason.
I tried to remove the redirect url form the app setup on YAMMER. The error still occurs!
Does anybody encountered this problem as well?
What could we do wrong?
Appreciate your help!
I found the solution. According to the documentation my first approach was correct. To use a dynamic redirect URL input the domain like this:
https://example.com
You can try to redirect to the default (http://yammer.com/). In the past you didn't need this parameter and it would always redirect to http://yammer.com.
See these out-dated docs:
https://developer.yammer.com/oauth2-quickstart/
Related
ive been doing a stephen grider course and he creates a google oauth client id with authorised js orgins as http://localhost:5000 and authorised redirect URI as http://localhost:5000/* and google accepts it. But when i try the same it throws me an error for redirect URI as Invalid redirect: Cannot contain a wildcard (*). And im not sure without this , further it will cause problems.Any way to solve this. Ive typed http://localhost:5000/ as a temp solution. Kindly suggest.
What ever course you are following must be very old I have been developing with Google for five years a wildcard redirect uri has not been allowed in that time.
Authorized redirect URIs
For use with requests from a web server. This is the path in your application that users are redirected to after they have authenticated with Google. The path will be appended with the authorization code for access. Must have a protocol. Cannot contain URL fragments or relative paths. Cannot be a public IP address.
Redirect uri must be a path to the file you wish to use to handle your authorization.
The redirect URL you configure to the API console must be an exact string match to the redirect URL you use in your app. So for example, http://localhost:5000 does not match http://localhost:5000/ or https:5000//localhost. Thus a wildcard will never work.
Furthermore, it's very unusual for a redirect URL to not have a path component. So something like http://localhost:5000/myoauth is more conventional. That's not to say that an empty path is impossible, simply that it's so unusual that it's more probable you have misunderstood OAuth somewhere.
However, note that you can configure several redirect URLs, so http://local:5000 and https://localhost:5000 and https://myliveservice.com/redirect
On this page, https://github.com/doorkeeper-gem/doorkeeper/wiki/Supported-Features, it mentions support for Implicit Grants. It looks like the authorizations#create is the endpoint I want and it does return an access_token but it doesn't return the other parameters that are required.
Request
https://localhost/oauth/authorize?client_id=<client_id>&response_type=token&redirect_uri=urn:ietf:wg:oauth:2.0:oob
I get redirected to:
Redirect
https://localhost?access_token=<access_token> with the body:
{"resource_owner_id":<user_id>,"scopes":[],"expires_in_seconds":7776000,"application":{"uid":"<client_id>"},"created_at":1484857630}
What I need per the spec, is a redirect with query parameters:
https://localhost#access_token=<access_token>&token_type=bearer&expires_in=<seconds>&scope=<scope>
Is the use of the testing redirect value of "redirect_uri=urn:ietf:wg:oauth:2.0:oob" changing the response?
Also notice the ? instead of the # just before the response query parameters. I'm not sure what the spec says on that but Amazon OAuth2 clients require the # sign.
How do I get the token_type=bearer be included?
Thanks.
I was able to get my service working by looking at the code. So the answers to my questions above are:
urn:ietf:wg:oauth:2.0: is called the native URI. There is branching in the code which alters the response when it's set to the native URI. Using ngrok to create an externally callable endpoint on my local machine, I used a true redirect_uri value and Doorkeeper responded with the correct parameters in the response (including the token_type=bearer and # sign).
Note: It worked from my Amazon Alexa skill only after modifying the Doorkeeper code to allow redirect URLs that contain query parameters. Amazon's redirect URLs are in the format https://pitangui.amazon.com/spa/skill/account-linking-status.html?vendorId=<vendorId> which is currently not supported by Doorkeeper and an error is thrown about an Invalid Redirect URI.
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.
Why do I continuously receive "The provided value for the input parameter 'redirect_uri' is not valid."?
My site is hosted in Azure. I'm trying to Login via the Microsoft sign-in button. I haven't really made many changes from the default ASP.Net MVC out-of-the-box template. All I've really changed was to uncomment the app.UseMicrosoftAccountAuthentication line and add the clientId and clientSecret.
Do I have the Redirect URL set up incorrectly?
Site: http://mysite.azurewebsites.net
Redirect URL: http://mysite.azurewebsites.net/
I read somewhere that you need to specify a Redirect URL in the form of http://www.mysite.azurewebsites.net. Can anyone confirm or deny that? I do not need the www in my current set up.
The error I consistently receive is:
https://login.live.com/err.srf?lc=1033#error=invalid_request&error_description=The provided value for the input parameter 'redirect_uri' is not valid. The expected value is 'https://login.live.com/oauth20_desktop.srf' or a URL which matches the redirect URI registered for this client application.&state=SomeLongPossiblyEncryptedString
This message is displayed on the page returned after an attempt to login:
Microsoft Account
We're unable to complete your request
Microsoft account is experiencing technical problems. Please try again later.
3/26/2014 Update: No luck so far, here's some screen shots of my settings in case it helps.
Basic Information
API Settings
Is this a problem on Microsoft's side or am I doing something wrong?
From the default MVC what works for me (just tested about 5 minutes ago) for the redirect URL is
http://testcrap.azurewebsites.net/signin-microsoft
All the documentation I've found says to use
http://testcrap.azurewebsites.net/login/microsoftaccount
But that doesn't work for me...
signin-microsoft does
OR if that doesn't work then use something like firebug to see what the request to the oauth provider looks like and then whatever the redirecturi is inside of that request is what you need to use..
For web application you need to set the redirect url in the Live Connect Developer Center.
In API Settings->Redirect URLs you must set:
http://www.yourdomain.com/signin-microsoft
Hope it's helpful :)
You need to provide the redirect url in the Live Connect Developer Center. I've attached a screenshot. This is part of the application validation to prevent malicious applications.
It seems Microsoft change the url again. This what works for me
.auth/login/microsoftaccount/callback
My redirect url is
https://yyyyyyyy.azurewebsites.net/.auth/login/microsoftaccount/callback
To get this url, use Fiddler or any http debug tool and look for request to login.live.com. The redirect_url is in the query string.
https://login.live.com/oauth20_authorize.srf?client_id=00000000551716B9&redirect_uri=https%3A%2F%2Fyyyyyyyyyy.azurewebsites.net%2F.auth%2Flogin%2Fmicrosoftaccount%2Fcallback&response_type=code&scope=wl.basic+wl.offline_access+wl.signin+wl.birthday+wl.calendars+wl.calendars_update+wl.contacts_birthday+wl.contacts_create+wl.contacts_calendars+wl.contacts_photos+wl.contacts_skydrive+wl.emails+wl.events_create&state=nonce%3Dfe7e6b678b8844f48f079cceadf1f426_20151206145117%26redir%3D%2F
Since I need 3 more reputation points to write a comment to your post I have to ask it here. Sorry about that.
Are you getting this error while trying it out on the real domain or while testing it from your localhost?
If the second is the case you need to setup a DNS entry for a dummy hostname in your local host file that points to 127.0.0.1 and use that dummy name when registering with live. Furthermore it needs IIS, not IIS Express.
Not sure if it is a clean way nor if it is complete, but it is the furthest I got when trying out the new ASP.NET Identitiy Provider. Sadly there is only a example in the official documentation which shows how to use it with google...
I, too, would appreciate a clean answer to this.
Redirect URIs are "SSL sensitive" and you probably always want the SSL version.
I'm implementing and OpenId Provider based on the DotNetOpenAuth OpenIdProviderMVC sample. From the RP, I'm creating an OpenIdRelyingParty, and calling CreateRequest with
http://localhost:PORT/User/xrds
This correctly redirects to the OP, and everything seems to work, but the ClaimedIdentifier that comes back is always
http://localhost:PORT/User/xrds
even when I'm expecting
http://localhost:PORT/user/username
where username is the user I logged in with. Is this an issue with the sample, am I using an incorrect URL as the UserSuppliedIdentifier, or is it something else?
Try to define a different URL as UserSuppliedIdentifier. For instance, use something like http://localhost:PORT/Discovery that executes an action returning the XRDS file. And for identity discovery, define a route to redirect http://localhost:PORT/user/username to a action Identity serving the XRDS file for identity verification.
That worked for me.
Good luck.