I am trying to configure OAuth via a connected app in my Salesforce instance. I am able to login, but I do not get an custom claims (Custom Attributes). I think what I need is to check the "Include Custom Attributes" checkbox. But when I edit the app, that checkbox is no where to be checked. I can only see it in the view.
I am able to check a similar box under "Configure ID Token", but that checkbox seems to have no effect on the OAuth setting.
In the end, I just need to see my claims show up in my remote app. But I just get name and email.
When you make initial call to /services/oauth2/authorize - what's your response_type? For example is it token+id_token?
You receive authorisation code valid for few minutes and then you swap it for the final response with access_token (a.k.a. SF session id), instance_url (endpoint to use from now on) etc.
Custom attributes will be included in the base64-encoded id_token - if you requested it.
And have you defined some custom attributes? They should be on related list at the bottom of the connected app's page but check that they exist in both places. There's the main app page (where you define OAuth2 scopes, can read the key & secret) - and there's the button to Manage Policies or sth like that (where you define which profiles/permission sets can use it) - custom attributes must be present on both pages' related lists.
Related
We are developing an TYPO3 extension that is in charge of managing the social network profiles. We used the extension "ps_social" as a guide for understand the social media network APIs could work with TYPO3 through Adapter Pattern.
I have the proof of concept of the implementation to authenticate a profile and publish in it but through only in PHP, now we want to take it to the TYPO3 extension.
My question is about the callback when authenticating a profile. Our extension sends us to the social network and when we return to our web page, with the token in the url, this does not change and shows the same screen of the plugin before redirect to the authentication in the social network. The callback url in manage app in Twitter has the id of our plugin's page. I check url for change the plugin action but doesn't work.
We see that this step is fundamental to be able to later make publications to the authenticated profiles in the application.
The problem could be that your authentication service is not triggered when returning to the TYPO3 site. Whether or not your service will trigger depends on several configuration options. By default, your service will only trigger when a POST login action is taking place - but there are options to define that, for example, the authentication service must always attempt to fetch (and thus authenticate) the user even if there is no POST login data (instead, GET parameters may be used to determine if authentication should be attempted).
There is also a caveat if you intend to log in BE users using this method. I've noticed that if you attempt to log in a BE user in the FE, then no action or configuration will be respected unless an existing BE user cookie exists (which it will if you've ever been logged into the BE). If you use the authentication service to log in to the BE normally there isn't this problem - it only applies if you try to do it in FE.
TL;DR: I'm guessing you need to configure the "always auth user" setting for the targeted BE/FE context, using parameters described in the "advanced" section of this link: https://docs.typo3.org/typo3cms/Typo3ServicesReference/Authentication/Index.html
The problem was resolved creating a new plugin. In the configuration of application in Twitter I can not set parameters as controller and actions, for example; only the page id. I had to create a plugin in my TYPO3 extension that execute in one page the action for get information of callback, process and return the page with the list of social profiles. This We did it in each one social networks (Facebook, Google+ and Instagram) for their callback URL to be correct.
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 have a google-marketplace-applciation (uses Oauth2) which allows google users to login to an external application via Google-SSO. This is currently setup by specifying an authentication REST endpoint of the external application in the "Universal Navigation link" section in the marketplace app.
My requirement is to capture any user specific attribute during the above request from marketplace-app to external-application. As per the documentation it seems "${DOMAIN_NAME}" is the only supported parameter in "Universal Navigation link". Apart from this is there any other auto populated parameter which can be used to uniquely identify the user (i.e. sub-Id, email) ?
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.
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.