Developing a web application that I've registered with Twitter. In this app, I might have 10 different Twitter Identities that I want to either Allow or Deny access for the application to.
For example:
https://api.twitter.com/oauth/authorize?oauth_token=XXXXXXXXXXXXXXXXXXXXXXXX&oauth_callback=http:://localhost:24649/TwitterIdentity/GetTwitterAuthorizationCallback/
It always just defaults to whatever my twitter account is logged in as and I have to specify Logout, then sign-in with new account. Its almost like I need an extra querystring parameter such as
https://api.twitter.com/oauth/authorize?oauth_token=XXXXXXXXXXXXXXXXXXXXXXXX&oauth_callback=http:://localhost:24649/TwitterIdentity/GetTwitterAuthorizationCallback/&ForUsername=billgates
Actually, you can pass in an extra parameter with the callback url, like so:
https://api.twitter.com/oauth/authorize?oauth_token=XXX&oauth_callback=http:://localhost:24649/TwitterIdentity/GetTwitterAuthorizationCallback?ForUsername=billgates
and the parameter will be sent back to you when Twitter calls the return url, like this:
http:://localhost:24649/TwitterIdentity/GetTwitterAuthorizationCallback?ForUsername=billgates&oauth_token=XXX&access_token=YYY
You can read more about this in the documentation - http://dev.twitter.com/pages/auth:
Always use an explicit oauth_callback
- It is recommended that you specify a default OAuth callback in your client
record, but explicitly declare your
oauth_callback on each request token
fetch request your application makes.
By dynamically setting your
oauth_callback, you can pass
additional state information back to
your application and control the
experience best.
Note that in the general scope of authorization, the authorized agent does not necessarily know the identity of the user on whose behalf it acts. In other words, there could be an implementation where your app can be authorized to read the Twitter stream of updates, while still not knowing which identity that stream belongs to. Adding the parameter you ask for would be information disclosure in this case, as your app will need a piece of information that the system is designed not to provide.
Or to put it in a real life example - imagine a valet parking, where instead of giving you a parking ticket and taking the keys to the car, the valet would ask you for your SSN just to park the car, just because the valet parks cars for other people too.
Related
i am trying to connect Smartsheet with Celonis. I already have a Client ID and Client Secret but everytime I try to connect both, Smartsheets shows an error saying Redirect URL ist missing or wrong. Thanks in advance
In the developter Settings of Smartsheet it asks for the APP URL and APP Redirect URL. I am currently still uncertain what to fill out in both fields.
As the App which wants to get the Data Sheet is Celonis, I have filled in an APP URL with the Celonis URL (something like -> https://xyz.celonis.cloud/package-manager/ui/studio/ui/assets/xxxyyy-11-123) and an APP redirect URL the Authorization Page URL (something like this -> https://app.smartsheet.com/b/autorize?form.....) and every other mixture of these and other URLs but nothing seems to work out.
I have also reviewed various Smartsheet Docs but found no answer until now.
First, registering an app in Smartsheet in the way that you’ve described is only necessary if your integration between Celonis and Smartsheet will use OAuth (i.e. Celonis will ask the user for permission to access their Smartsheet data and if approved by the user, then Celonis will be able to programmatically access the user’s Smartsheet data). Is this the functionality you’re trying to achieve?
If NOT (i.e. Celonis doesn’t need to make API calls as each specific user that connects to Celonis) — then you don’t need to register the app in Smartsheet. Just create an access token in Smartsheet for the app to use, and make sure the user (account) that owns the token has permissions to access the necessary sheets in Smartsheet.
If YES (you are trying to implement OAuth so that Celonis can access the Smartsheet data of the user that’s logged into Celonis)….then here’s some info about those two fields:
App URL is just the application’s main URL. For example, if I was implementing Smartsheet OAuth in my app where the home page was http://www.abctest123.com then that’s the value I’d enter in the App URL field when registering the app in Smartsheet. As far as I know, this field isn’t used for anything in the OAuth process — it’s purely for reference purposes.
App Redirect URL is the address of the page in your app where the user will be redirected after they choose Allow or Deny when they’re asked whether or not Celonis can access their Smartsheet data. This needs to be a valid page URL, for a page that you’re able to configure to read any query string parameters that are present in the URL — because when redirecting the user to that page, Smartsheet uses query string parameters to indicate whether the user allowed or denied access, and if they allowed access, to specify the authorization code and expiration info for that code.
If you need more info, the OAuth process is described very well in the Smartsheet Dev Docs: https://smartsheet.redoc.ly/#section/OAuth-Walkthrough.
I'm using the LinkedIn API to authenticate users. After authentication LinkedIn posts data back to my app at /auth/linkedin/callback (as is the OAuth standard).
I also offer other auth methods (e.g. Google+, Twitter, etc..). If the user signs in with one of those, I want them to also be able to (on top of their existing auth) connect with LinkedIn to pull in additional data.
In those cases, I want the callback URL to be something different so I don't have to do some very custom if...then logic.
Is there a way to specify in an OAuth request where you want to call back to?
If #1 isn't possible, can I send some custom arbitrary data or flags with my initial request that are returned during the callback? That way when parsing the response I'll check those flags for the appropriate state of the User and redirect them as necessary.
Thanks!
The state parameter is guaranteed to be preserved across all interactions. You can store (encoded?) information in it, and when the final callback is called, you will get back the original value you sent.
A common use case is capturing the "end URL" for the user (like a deep link into your app that requires auth).
You are supposed to check that what you receive is exactly what you sent.
I'm working on a cloud-storage API, authorized via OAuth. Users of third-party applications can permit said application to access their files/data via our RESTful API.
Currently, we are limiting a third-party app access to a users account once. E.g., the Access Token table has a UNIQUE on the consumer column and the user column. This makes sense at first glance, as the user should never be sent to our service to authorize a third-party application twice, since the third-party would already know their user is already tied to our service and wouldn't need to be re-authorized.
However, what if this user has two accounts on the third-party app, and they want said app to connect to their single account on our service twice? This seems likely, given the prevalence of multiple accounts on services such as Reddit.
Here are the possible solutions I've come up with so far, none of them being perfect:
Display an error during the second auth request: This seems like a frustrating experience for the user, a "cop out" of sorts.
Delete the previous token: This would likely annoy the user, as their previous accounts stop working. Even if we display a warning, it would likely be hard to explain what exactly is happening.
Return the same access token as the first request: Each time the access is requested, a set of permissions are also passed along. The permissions for the second request could be different than the permissions for the first request. Also, not sure if this will violate the OAuth spec, as the secondly generated Request Token isn't tied to the Access Token properly.
Allow two to be generated: This would be confusing, as when the user visits their screen full of authorized applications to revoke one, they don't know which authorization is tied to which third-party account. We could ask for an optional third-party username parameter when the Request Token is generated to identify the different auth's (we currently ask for a non-OAuth-standard permission parameter already). But, this seems like it wouldn't be used by 99% of developers and could make application development more confusing.
What is the best way to handle this situation? Is there a standardized practice for handling this use-case?
I think your last case is the right way to go - Allow two to be generated
When the user visits his screen full of authorized application, it's not necessary to show him one and the same Application twice - you just have to delete the tokens associated with the app if the user revokes application access. That is, all his authorizations to the app with all tokens will go away with the revoke, which is fine.
I've got an existing Google Drive enabled application that's using the Google Java client library and server flow auth.
If you're not logged into the application and navigate to the URL AND you have logged into more than one google account on that browser (only one personal Google account is possible, any additional ones have to be Google business accounts) the OAuth callback offers the options to select which Google Account to use.
However, whilst testing a switch to using the JavaScript client library I'm not able to activate the multiple account selection screen using gapi.auth.authorize. Is it possible to handle multiple accounts using the JS library?
Update : I tried with the immediate parameter false. I can log in as long as I don't change account in the popup. If I do change account, I get to:
https://accounts.google.com/o/oauth2/auth?client_id=433863057149.apps.googleusercontent.com&scope=https://www.googleapis.com/auth/drive.file+https://www.googleapis.com/auth/drive.install+https://www.googleapis.com/auth/userinfo.email+https://www.googleapis.com/auth/userinfo.profile&immediate=false&redirect_uri=postmessage&origin=https://drivedrawio.appspot.com&proxy=oauth2relay593063763&response_type=token&state=701344514&authuser=1
in a new tab and nothing happens. I've made a video to demonstrate.
Update 2 : This bug against the JS client library for the need for double selection of mulitple account has been accepted.
You are not getting the multi user selection screen because of the following parameter: authuser=0
This automatically selects the first account you are signed-in with (authuser=1 would select the second etc...).
It's currently not possible to remove that param using the client library because the client library sets it automatically to 0 (this is why it claims not to handle multi-accounts) if there is no value so one way is to override it to -1 for example, this will show the multi-account chooser. Then you could also ask to access the user's profile or email at the same time you ask access to other APIs and fetch either the email of the user or its ID. Then on subsequent auth you can specify the user_id param which wil bypass the user-selection screen.
So in practice, first authorize like this:
gapi.auth.authorize({client_id: <Your Client ID>,
scope: 'https://www.googleapis.com/auth/drive openid', // That requires access to Google Drive and to the UserInfo API
authuser: -1});
The only problem with the above is that the auto-refresh of the client library will not work because every auth will by blocked at the multi-account selection screen.
The trick is to get the ID of the user using the UserInfo API, save that ID in a session cookie and use it on subsequent auth like that:
gapi.auth.authorize({client_id: <Your Client ID>,
scope: 'https://www.googleapis.com/auth/drive openid',
user_id: <The User ID>,
authuser: -1});
Specifying the User's ID will make sure the multi-account chooser is bypass and will allow the auto-refresh of the token from the client lib to work again.
For reference, other URL param that impact the User flow are:
user_id: similar than authuser (bypasses the multi-account selection screen) but you can use email address (e.g. bob#gmail.com) or the User ID you get from our Open ID Connect endpoint/Google+ API/UserInfo API
approval_prompt: default is auto, can be set to force to make sure that the approval/grant screen gets shown. This makes sure that the gant screen is not bypassed on subsequent auth (after first time).
immediate: immediate is a bit tricky, when set to true it will bypass the grant screen (kinda like approval_prompt=auto) if the user already granted approval previously, but if the user has not granted approval previously you will get redirected with an error: error=immediate_failed. If set to false it won't add special behavior and therefore fallback on the behavior setup by the approval_prompt value.
Note: immediate=true and approval_prompt=force is an invalid combination.
I think the client library is using the immediate param so that if he gets the error=immediate_failed it will restart an auth flow without the authuser param, but that's only speculations :)
The OAuth grant access page is only shown when not in immediate mode, does it work as expected if you set the immediate parameter to false?
According to http://code.google.com/p/google-api-javascript-client/issues/detail?id=11
multi-login isn't supported by the Javascript client
Pay attention to authuser parameter. Set this to "2" for example and you will be prompted for login even if you are authenticated already.
I'm following the client side authentication as described at https://developers.google.com/accounts/docs/OAuth2UserAgent
I am routinely signed on to multiple Google accounts. Normally, the flow will prompt me to choose which account I want to authenticate with. However there are sometimes instances where it assumes the first account I signed in with, which is not the account I wish to use.
When users register with my service, they do so with a specific email address (and google id).
How do I qualify the oauth dialogue such that it will always take place using only the specified user?
On https://developers.google.com/drive/about-auth I can see a comment...
Note: If you want to use the user_id parameter to select the current user from
(potentially) multiple logged-in accounts,
also add https://www.googleapis.com/auth/userinfo.email.
The implies that there is a user_id parameter I can include in the oauth call, but I can't see it documented anywhere, and there is nowhere in the Javascript API where I can inject a user_id.
Add the user_id parameter to your Authorization URI.
gapi.auth.authorize({..., user_id: 'ali#gmail.com'}, handleAuthResult);