After successful OAuth sign in, google redirects to the URL with the state and scope queryparam without encoding, such as the one mentioned below:
https://example.com/oauthhanlder?state=https://example.com?action=googleOAuth&scope=https://mail.google.com/
Before it was redirecting as
https://example.com/oauthhanlder?state=https%3A%2F%2Fexample.com%3Faction%3DgoogleOAuth&scope=https%3A%2F%2Fmail.google.com%2F
Related
I want to implement oAuth2 flow in my Slack app, but it's impossible to test properly.
I have added /slack/redirect-url as a redirect URL on my App management page. Then try to install\reinstall the app on the following page:
Unfortunately, it doesn't work, my endpoint isn't called.
However, if I go to the "Distribution" section and try to install the app from there it does call my redirect URL:
So, what's the issue? Why the first approach doesn't call my redirect URL, but the second one does? Am I missing something fundamental?
The "Reinstall App" button will handle the entire exchange of verifying and granting the OAuth token within Slack, so there is no need for the redirect.
The redirect URL is intended for users who are authenticating with your service, and thus you need to store the token.
User clicks the install button
User authorizes through Slack UI
Slack redirects to your desired URL
You grab the code included in the redirect call
You exchange the code for the OAuth token
You store the OAuth token
When you use the "Reinstall App" button in your app management view, steps 3-6 are handled entirely by Slack and the token is displayed to you.
To properly test the redirect URL, you can go through the OAuth flow manually. Given that they're simply GET requests, you can just modify the links and paste directly into your browser.
Step 1: Authorize the app – this will send you to Slack for authorization, and then your redirect
https://slack.com/oauth/authorize?client_id=CLIENT_ID&scope=SCOPES&redirect_uri=REDIRECT_URI
Step 2: Exchange the verification code for OAuth token
https://slack.com/api/oauth.access?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&redirect_uri=REDIRECT_URI&code=CODE
I'm trying to use Spring Social Facebook login along side form login, more or less following the guide here: http://www.baeldung.com/get-user-in-spring-security, only using header-based session management rather than cookies. Right now the login is successful. Facebook sends a 302 to my server at /api/signin/facebook, and my server sends a 302 to the post-sign-in url I've set on my ProviderSignInController along with the x-auth-token header. The issue is that when following the last redirect my browser throws away the auth token.
I think I want to just add the auth token as a query param on the final redirect uri, but I don't know how to intercept the final response. I've called setSignInInterceptors on my ProviderSignInController but that seems to be ignored after the first sign in. How can I keep my session information when it's not a cookie?
Just added the token as a query parameter and returned it from my custom SignInAdapter.signIn method. I feel like there's probably a better solution but I needed something.
redirect_uri parameter for the authentication URL for the server-side flow hasn't work when a user has to sign in to Yammer after visiting the authentication URL.
The current situation is as below:
A user visits
https://www.yammer.com/dialog/oauth?client_id=[:client_id]&redirect_uri=[:redirect_uri]
He's redirected to
https://www.yammer.com/dialog/authenticate?client_id=[:client_id]
"redirect_uri" is being missed here.
He signs in with his Yammer account. He is redirected to his Yammer home, not redirecting back to [:redirect_uri].
Could you please investigate if it's an issue to be fixed?
use the below code.
https://www.yammer.com/oauth2/authorize?client_id=[clientid]&response_type=code&redirect_uri=[redirect url]?error=[:error]&error_description=[:error_description]
Replace your client id and redirect url only in the above line. Rest keep the same.
Also, Please make sure the redirect url you have mentioned while registering the app key matches with the redirect_uri above.
The authorized redirect URI is used by google to do a callback to pass the authorization token.
It is also used for validation by google. So when receiving the actual oauth request, google checks to see if the callback url given in the request is same as "Authorized redirect URI" and if not it throws error.
My requirement is to prevent google from doing this validation as I want to be able to pass different callback urls at run time . I tried giving the "authorized redirect URI" as empty, but that doesn't work. Any suggestions ?
Yes, in Google OAuth 2.0, although you can set no uris in REDIRECT URIS, it doesn't make any sense. Redirect uri is required in client registration and oauth flows(authorization code flow and implicit flow).
Lack of a redirection URI registration requirement can enable an attacker to use the authorization endpoint as an open redirector.
You mentioned that LinkedIn enabled open redirectURI. This is not acceptable in security. And I've noticed that LinkedIn has fixed this issue.
In order to make the LinkedIn platform even more secure, and so we can comply with the security specifications of OAuth 2, we are asking those of you who use OAuth 2 to register your application's redirect URLs with us by April 11, 2014.
Here is LinkedIn's announcement.
No, Authorised redirect URI is NOT mandatory.
See, for example, https://developers.google.com/+/web/signin/javascript-flow
The quickstart example even shows how you might use different callback URLs
I have implemented an OAuth2 authentication mechanism in my GWT app. The OAuth2 server is based on Spring framework 3.x (using its Spring security OAuth2 implementation).
I am using the OAuth2 "Authorization code flow" to get the user authenticated (though implicit flow may have been a better choice in our case). So at first, the user is redirected to the OAuth2 server authentication page, he enters his credentials and if he is successfully authenticated, he is redirected back to a url with an oauth code. He will then make a second call to get an access token from the OAuth2 server.
Now, the issue is, we would like the user to be able to bookmark a page in the application and directly access it. If he has already authenticated then he would have direct access to it (no more auth involved). Otherwise, he would have to go into the OAuth2 authentication flow but in the end, should be redirected back to the bookmarked page he intended to access at the beginning.
How can I store this page url and get redirected to it after the user successfully authenticates ?
any help would be appreciated. Thanks!
EDITED
The initial url redirection is done via javascript's document.location.href
The way to maintain the original URI in an OAuth 2.0 Authorization Grant flow is to pass it in the state parameter so that the redirection endpoint can use it, after it exchange the authorization code for an access token, to redirect the user back to that URI.
FYI, this is exactly what Google suggests in the examples in their OAuth 2.0 documentation, e.g. https://developers.google.com/accounts/docs/OAuth2Login
Original answer:
The problem is using the hash part of the URL for the place, which is not sent to the server and thus cannot be used in the redirection to the OAuth2 server authentication page.
You have 2 (maybe 3) solutions:
stop using the hash for the place and switch to HTML5 History; either through gwt-pushstate at the History level, or a custom PlaceHistoryHandler.Historian if you use the Places API. That limits your audience though: http://caniuse.com/history
stop using an HTTP redirect, and instead use JavaScript so you can put the hash in the OAuth2 redirect_uri. So instead of redirecting, send an error page with the appropriate scripts bits.
some browsers append the hash to the URL after a redirection, so your OAuth2 server might be able to pick it (in JavaScript) and append it to the redirect_uri. That might depend on the HTTP status code used for redirecting (from experience, it works with a 301, but you don't want a 301 here). Needs testing.
You can do this using GWT activities and places.