I am currently using implicit flow to link user's account for Google assistant use. The linking works perfectly, the user is redirected to my website to login, user logs in and is redirected to the following url with access_token generated by the website.
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING
Google.com page is now displayed, which I assume means account linking has been successful. The problem however is on subsequent calls the access_token sent to API.ai is different then the one I sent back as a URL parameter.
I am failing to understand why this is?
NOTE: I am testing on Google Home Web simulator
For starters, check to make sure the other parameters in the URL for the google.com page actually do indicate a success. They may show an error.
If you are repeatedly testing with the same user, you may need to remove permissions to your application in between each test. You can do this at https://myaccount.google.com/permissions.
Since tokens never expire with the Implicit Flow, it is possible that Google is using an old token and never accepting one of the new tokens you're issuing, but always using the original token you issued.
Related
I'm writing an offline application that uses the Dropbox API. When a user comes to the application, I'm using the https://api.dropbox.com/oauth2/token (docs) to get a refresh_token, which I store for later use.
I am calling the same endpoint every time the user logs in (unless I've already got the user's data in a cookie). I'm not sure that this is the best way to go about it: I at least need to get the user's account_id, so that I can look up their refresh_token in the database if I already have it. But every time I call https://api.dropbox.com/oauth2/token, the user is redirected to the Dropbox app authorization interface, as if they've never approved the app before.
So I would either like to know how to stop Dropbox from forcing the user to re-authorize an app every time. Or, if that is just how https://api.dropbox.com/oauth2/token is supposed to work, I'd instead like to be able to get their account_id somehow when they visit my page.
(In case it's relevant, the app is still in development mode at this point.)
The https://api.dropbox.com/oauth2/token endpoint is an OAuth endpoint that the app can call to get an access token/refresh token. Being an API endpoint, it does not itself redirect the user to the Dropbox app authorization page.
The Dropbox app authorization page is at https://www.dropbox.com/oauth2/authorize (documented here), and the app decides if/when to direct the user there to authorize the app.
You generally only need to send the user through the app authorization flow (sending them to https://www.dropbox.com/oauth2/authorize and then calling https://api.dropbox.com/oauth2/token) once per user for an "offline" application. Once you do so, you should store the resulting refresh token for that user. You'll typically store the refresh token for that user tied to their user account in your own app.
Exactly how you manage the user accounts in your own app will depend on how it's built, but, as it sounds like this is a web app, typically you would use the user's browser cookies to identify the user when they return to your page so that you can look them up in your database and retrieve their details, such as their corresponding refresh token. (Or, if they're not already signed in to your web app, you would have them do so first.)
Greg's answer is very helpful, and very politely addresses my misunderstanding of the auth flow. (I was revisiting old code I'd written years previously—obviously I should have documented it better than I had!)
In the end I believe that Dropbox was forcing me to reauthorize because my application was in development mode, and had a small user base. When I used the identical code in an app set to production mode, it stopped forcing me to reauthorize. So the “problem” is really a Dropbox security feature, and the solution was just to use production mode.
I'm using hosted screen of Auth0. I want the following scenario to work-
Let's say I have 2 apps- app1 and app2.
One of the users signed in by providing email+password in app1.
User then navigated to app2.
Auth0 detected that the user has already signed in, so it redirects the user back to app2 WITHOUT having her signed in again.
But what I'm facing is this screen-
How can I save my user this additional click? How do I implement silent authentication? I know that you have to pass prompt=none to /authorize api, but since I'm not manually calling the api, how do I make the lock call /authorize with prompt=none?
What you want is silent SSO which is related to SSO but kind of independent.
The key is in the prompt param. This needs to be none in order for the user to not be prompted for login when he's already logged in Auth0's Authorization Server ("central SSO").
One annoying thing I found is that prompt is taken literally, so if the user is not logged in yet, he will not be prompted to login (you'd think it'd make sense to prompt the user when not logged right?).
In this case SSO will redirect to your app's /authorize with an error like "authentication required" and you'll have to handle it by redirecting the user to your /login endpoint again but passing prompt=true so that it knows that this time he'll have to pass prompt=true to Auth0's hosted login page.
To make things a bit uglier, currently passport-auth0-openidconnect seems to ignore the params you pass to the strategy unless you monkey patch one of the methods involved (I created a PR for it, don't when will be approved and/or if makes sense).
Essentially:
Pass prompt=none
If user is already logged in, he will silently be logged in your app as well
If user not logged in, user will be redirected to your app with "login required" error
In that case you'll have to pass prompt=true
I know it's a bit fiddly but I hope this helps you :)
PS: Another thing to bear in mind - I now just found out that it works perfectly when using Github as connection but when using google-oauth2 it blows up complain about the prompt param :|
I am learning to use dropbox APIs and got confused when came up with the token flow.
As guide indicates, the flow should be like this:
the app redirect the user to a Dropbox webpage, i.e. .../oauth2/authorize
user logs in and approves the app
redirect back to the app. At this point, the app gets an access token.
However, when i requested the URL:
.../oauth2/authorize?client_id=xxx&response_type=token&redirect_uri=xxx
I was directly redirect to the destination with
REDIRECT_URI = "#access_token=xxx&token_type=bearer&uid=xxx"
And the "approve step" was skipped, i.e I got an access token without being allowed.
Is it a bug or my fault?
Any help would be appreciated :]
In certain cases, when the user has already approved the app to access their account previously, they will be automatically redirected through the app authorization flow.
If you want, your app can prevent this behavior from happening by using the force_reapprove parameter, documented for the /oauth2/authorize page here:
https://www.dropbox.com/developers/core/docs#oa2-authorize
I have a Google Apps Marketplace (v2) app I am working on setting up Oauth2 for.
I've got everything working, but for some reason when I do a redirect to the authentication page, after, after you select which Google account to use (if like you're me and are testing, you have to pick one of several Google accounts you're currently signed into), I get sent to another page which seems utterly pointless:
This is bizarre and annoying, because I am logging in as the domain administrator!
Does anyone know a way to skip this screen, or what I might be doing to be cursed with this terrible user experience?
I just confirmed that having access_type=offline will always display this page, even with approval_prompt=auto. You will always get back a refresh token as well.
The only way to hide it is to remove access_type=offline on future login requests (ask only on signup).
I believe this shows up only if app requests refresh token for offline access. Also this should only appear first time you access the app after installation.
In order to skip this you need to update app to not request refresh tokens.
I'm currently implementing an Oauth consumer service which is going to use Soundcloud as an Oauth service provider as well. But I'm having the following issue with it: Taking Facebook or Twitter example, you go there, you sign in, you fill up the permission form, and you are redirected back to your app. If you go there a second time, and given you are already sign in, you basically skip all steps and are redirected back instantly. That means, Facebook recognized that you already gave permission to that 3rd party service, so it doesn't ask your permission constantly.
And that's what's happening when I use Soundcloud. Basically everytime I redirected the user to the Soundcloud Oauth connect endpoint, the permission form always shows up, even though I already gave permission to that 3rd party service previously. I'm forced to press "connect" every single time, which is a drag from the user perspective (how many times can you give permission to the same entity). My question is: is there a parameter I can use to make soundcloud recognize/validate the previous permission from the user account to that specific 3rd party service? Or is this Soundcloud Oauth design implementation and we have to live with it?
Edit:
Maybe this wasn't clear, but each time I press "connect" in soundcloud, a new access token is being generated and delivered. Since my app uses this access token to identify its users, it doesn't work very well for me that the access token is getting updated everytime I want to log in, making me effectively "sign up" everytime. To sum it up, I want to get the previously attributed token to my account, so I can look up in my database, identify it and log him in.
I'm also looking for a solution which doesn't involve storing state in the client that might get cleaned up.
What you can do is store the user's oauth token in local storage and reuse it in future sessions. That's what happens on soundcloud.com.
A longer explanation:
When you use the Connect flow, the user is authenticated by SoundCloud (either by using username/password, Facebook Connect, or an already-existing session on soundcloud.com), and then when it is successful, your app is given an oauth token for that user. This is passed to the callback page which is registered for your app.
That token is the only piece of information needed to have the user be "logged in". Unless the token expires (by time, or by the user manually revoking it), then you can reuse that in future sessions.
I think I'm a bit confused about your application's design: where and how is the oauth token being used? I think that instead of using the token as an identifier, perhaps the user's permalink might be better? If you have the oauth token, you can find out the permalink by querying api.soundcloud.com/me.