Previously asked this question in the Salesforce StackExchange which they considered off-topic so asking here to see if I can get an answer.
Background
I am attempting to use the immediate parameter to check if a Salesforce user has already approved access when going through the Web Server OAuth Flow as documented on OAuth 2.0 Web Server Authentication Flow. My reasoning for this is that I do not want the login or consent prompts to appear so I can reject access if they have not already approved.
Once the callback page is hit, I am always receiving the parameter error=immediate_unsuccessful even if the user has approved the application before and is logged in.
I have attempted to check this via a customised Google OAuth 2 Playground and setting immediate=true or immediate=false to the end of the authorize endpoint. On =false, the consent prompt shows and then you can grant access. On =true, this returns the same error as listed previously.
The Connected App that has been set up has api and refresh_token as the available scopes, users are able to authorize themselves and there are no ip restrictions set. The client id and secret from this app is then passed into the OAuth 2 Playground.
Below is a brief example on how my proper application redirects to the auth url using Java and the Google OAuth client library. We initially authorize the client without the immediate and then later on call the same code with immediate=true (shown in example)
AuthorizationCodeFlow authorizationCodeFlow = new AuthorizationCodeFlow.Builder(BearerToken.authorizationHeaderAccessMethod(),
httpTransport,
GsonFactory.getDefaultInstance(),
new GenericUrl("https://login.salesforce.com/services/oauth2/token"),
new ClientParametersAuthentication(CLIENT_ID, CLIENT_SECRET),
CLIENT_ID,
"https://login.salesforce.com/services/oauth2/authorize")
.setCredentialDataStore(StoredCredential.getDefaultDataStore(MemoryDataStoreFactory.getDefaultInstance()))
.build();
AuthorizationCodeRequestUrl authUrl = authorizationCodeFlow.newAuthorizationUrl()
.setRedirectUri("https://72hrn138.ngrok.io/oauth/callback")
.setScopes(ImmutableSet.<String> of("api", "refresh_token"))
.set("prompt", "consent")
.set("immediate", "true");
response.redirect(authUrl);
Question(s)
Are there any settings that I may have missed in Salesforce that would alleviate the error?
Is there any other option in the OAuth 2 spec that has to be set for the immediate option to work?
Does the immediate setting work?
I managed to solve this issue in the end. To allow the immediate=true option to work, the scopes have to be removed from the request. In the example provided you would amend the authUrl to the following:
AuthorizationCodeRequestUrl authUrl = authorizationCodeFlow.newAuthorizationUrl()
.setRedirectUri("https://72hrn138.ngrok.io/oauth/callback")
.set("prompt", "consent")
.set("immediate", "true");
I believe the theory is that defining a scope means you are asking for permissions to use those scope and therefore requires approval for those permissions. This clashes with the immediate option which states that the user must be logged in and the client id already been approved for it to succeed.
Related
I'm implementing Google's 'code model' of Oauth2 and having trouble getting users' email - I wonder if this is a scopes problem or my misunderstanding about how to set up the code model. This sequence of events is already working:
Client loads https://accounts.google.com/gsi/client
Client starts call to google.accounts.oauth2.initCodeClient
Client gets code
Client passes code to one of my server endpoints
Server has an oauth2Client set up using the config with client_id, client_secret, and redirect URL = 'postmessage'
Server exchanges the code from the client for tokens
Server does oauth2Client.setCredentials(tokens) - this contains an access_token, which is enough for the client to make API calls to, e.g., retrieve the user's Google Calendar
Server is able to do oauth2Client.getTokenInfo(tokens.access_token);
There are various places along the way that involve scopes; I am probably getting something confused here. The client's initial call (step 2 above) uses
scope: 'https://www.googleapis.com/auth/calendar',
My code path on the server does define scopes anywhere.
In GCP, my project is set up with scopes
calendar.calendarlist.readonly, calendar.readonly and calendar.events.readonly
openid
/auth/userinfo.email
Here's the problem I'm encountering: when I go through this flow as a user and oauth with the account that owns the GCP project (this is a Google Workspace email, in case that matters), the tokens object that the server receives (step 6 above) has access_token, refresh_token and id_token - the id_token can be decoded to yield the user's email, and the user's email is also in the response to oauth2Client.getTokenInfo(token.access_token).
However, when I go through the flow with my other (personal) Gmail account, the tokens object that the server receives is missing the id_token but has the access and refresh tokens. Question 1: why are the responses different?
Question 2: How can I get the email of the user on the server in the personal Gmail account case? I've tried having the server make a call to https://www.googleapis.com/oauth2/v2/userinfo?fields=id,email,name,picture with the access_token, but this fails. I am not sure if I'm supposed to declare scopes for oauth2Client somehow, or tap a Google API using a different method on the server.
I think I've had a breakthrough: in step 2 in my original post, when I did "Client starts call to google.accounts.oauth2.initCodeClient", I had set the scope of initCodeClient to just the calendar scope. When I changed it instead to scope: 'https://www.googleapis.com/auth/calendar https://www.googleapis.com/auth/userinfo.email openid', (scope takes a space-delimited list in this case), it allowed my server call to get the id_token for this user and oauth2Client.getTokenInfo to get a response with the user's email in it.
When I updated the scopes like that, the popup asking for authorization also updated to request all the scopes I wanted - previously, it was only asking for the Calendar scope, so it makes sense Google didn't want to return the email.
What I still don't understand is why my previous setup was working for the account that owns the GCP project. In other words, when I was first building it out with that owner account, the client was only noting the Calendar scope while the server was asking for all three scopes (ie there was a mismatch), and the server was still able to get an id_token and the user's email in getTokenInfo. Maybe the owner account has some special privilege?
I'm trying to learn about OAUTH and OpenID Connect.
Thus I am investigating my own traffic, listening to Authorization Requests and Grants by checking for required parameters in OAUTH as described in https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1 and https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2 for the Authorization Code Flow as well as described in section 4.2.1 and 4.2.2 for the Implicit Flow.
Unfortunately, by using the SSO option for Google on joinhoney.com, I am only able to catch the Request, but not the Authorization Grant.
So, while debugging and having a look at the actual request, I can see the following parameters in the query part of the url:
Parameter
Value
redirect_uri
storagerelay://https/www.joinhoney.com?id=auth[censoredID]
response_type
permission id_token
scope
email profile openid
openid.realm
client_id
705229005811-2fdpup66d8aefq4qs2ru1n8qiosuq4fb.apps.googleusercontent.com
ss_domain
https://www.joinhoney.com
fetch_basic_profile
true
gsiwebsdk
2
Now, to get to the actual question:
Where can I find some specified information about the ss_domain parameter?
I could not find any information in https://www.rfc-editor.org/rfc/rfc6749 as well as on https://openid.net/, however when using google, I can find some people using the ss_domain parameter (only without further explanation), so I doubt it is something only used by joinhoney.com.
Would be happy if somebody could bring some light in here!
Thank you!
If you are at www.example.com, and you your redirect_uri is to a different domain e.g. subdomain.example.com, you need to set ss_domain to https://subdomain.example.com.
This custom ss_domain change, however, is not possible using the Google login client side sdk. You got to push the url manually.
I have an identity server built with Identity server 4. There is one main API with several angular web applications build by third party customers that access this API endpoint.
Now I would like to create a second API but its only for internal use with OUR official plugin. I am trying to figure out how to lock it down so that only our app can access it. I am not a fan security by obscurity and assuming that the third party's dont know its there so wont try and access it.
My first thought was to add a new scope for this API but by doing that its going to popup and ask the users for access to the data which isnt really need.
The only thing i can think of would be to check the client id some how in the API and add a policy for it. This really isnt right ether as to my understanding polciy should be checking stats of the user and not the client itself.
services.AddAuthorization(
options => {
options.AddPolicy("DevConsole", policy => IsClientId(xxxx)
}
);
Is it possible to lock down an API based upon a single client id? or am i going at this in the wrong way.
Another idea i had was to add another claim if they login with this client id which seams like overkill to me.
Example:
Lets say that I have an API endpoint that allows you to update the usersname. All users have access to their name this isnt a scope issue. However only our official app has access to update the usersname. Any app created by third party developers do not have access to the endpoint to update a usersname.
So our official plugin has a client id of 123 and yours has a client id of 321. A user logged though client id 321 can not access this endpoint. User logged in though client id 123 can.
I am starting to think this isnt possible because Oauth and Openid are completely user based. There is no way to validate the user based upon the client they authenticated with.
if I understand the problem correctly, I would create a new Client on Identity Server, for the "main API" and a new Resource for the "internal API"
This would allow the "main API" to also be a client, with client credentials grant type, therefore it has a id+secret and is allowed to request a token for itself. In this case, you will now request the newly created scope for in "internal API" and the users will have no knowledge that this entity evens exists.
After going back and forth with this with this it occurred to me that the client id is returned as a claim. So when i got in this morning i checked.
This should enable me to add a policy for only our official plugin.
services.AddAuthorization(options =>
{
options.AddPolicy("IsOfficalApp", policy => IsCheckOfficalClient());
});
This should enable me to lock down the API endpoints in question without requiring additional authorization from the users.
I'm making requests against the Instagram API from a mobile app. Currently, I'm just directing the user to the Instagram auth url and specifying the response type to be "access_token". Specifying this response_type is known as implicit auth.
Explicit auth: response_type=code
Implicit auth: response_type=access_token
I'm trying to get around needing to stand up a web service to facilitate explicit auth. This would be necessary because in explicit auth flow, the Instagram API needs to make a call to a redirect URL and pass in a "code" parameter. The code would then be used by my server-side code to make a final request to Instagram for an access token.
It's much more efficient for a mobile app to use implicit flow because no extra privately-maintained auth service needs to be stood up to handle it.
Instagram supports the following scopes:
basic - to read any and all data related to a user (e.g.
following/followed-by lists, photos, etc.) (granted by default)
comments - to create or delete comments on a user’s behalf
relationships - to follow and unfollow users on a user’s behalf
likes - to like and unlike items on a user’s behalf
When I make any other type of scope specification besides "basic", I get the following response when the user provides the credentials at the auth URL:
{"code": 400, "error_type": "OAuthException", "error_message": "Invalid scope field(s): basic+likes"}
Any combination of scopes other than "basic" gives the same response.
So, my question are these:
Is explicit auth required in order to specify scopes beyond "basic"??
Do I need to specify response_type=code in order for extended scopes to work?
Is this an Instagram limitation, or is it a limitation of OAuth 2.0?
Thanks in advance.
I just tried with implicit oauth flow with my client_id and scope=basic+likes and it worked. Replace the url below with your client_id and redirect_uri, and try.
https://instagram.com/oauth/authorize/?client_id=CLIENT_ID&redirect_uri=REDIRECT-URI&response_type=token&scope=basic+likes
May be Instagram is not allowing scope other than basic with new client accounts...
The answer here is that YES, scopes can be requested by implicit auth flow just fine. My problem was related to an OAuth component that I was using. The component was silently URL-encoding the value of the scope param, which was rejected by the Instagram auth endpoint. I updated the component (Xamarin.Auth) to accomodate a non-encoded scope param and issued a pull request.
Thanks to #krisak for providing a working URL that I could test.
So I had similar issues regarding the encoding of the + when trying to get permission for multiple scopes (basic, likes, comments). The solution I found was to use spaces between the individual scopes:
In the config/initializers/omniauth.rb file:
Rails.application.config.middleware.use OmniAuth::Builder do
provider :instagram, 'TOKEN', 'SECRETKEY' , {:scope => "basic likes comments"}
end
Unfortunately starting from April 14th 2015 new clients cannot get access for any scope but basic. Official message could be found at the client configuration page:
Starting April 14th 2015, new clients need to request access to be able to post likes, follows, and comments. For more information please read the Developer Blog at http://developers.instagram.com.
The message refers following blog entry: http://developers.instagram.com/post/116410697261/publishing-guidelines-and-signed-requests
Instagram requires personal request to be sent to enable scopes for your application (client ID), but your app has to meet certain conditions described in the blog entry.
i have the same problem i found this solution and works fine
Go to Manage clients under instagram/developer. Then click edit under your app and uncheck Disable Implicit OAuth. It will now work as intended.
Instragram changed this for a reason though, so should probably think twice before going public with your app: http://instagram.com/developer/restrict-api-requests/
At this time, May 2015, YES.
As explained on instagram documentation about authentication:
The Instagram API uses the OAuth 2.0 protocol for simple, but
effective authentication and authorization. OAuth 2.0 is much easier
to use than previous schemes and developers can start using the
Instagram API almost immediately. The one thing to keep in mind is
that all requests to the API must be made over SSL (https:// not
http://).
You first need to register your app here and then, with CLIENT ID provided by instagram, you can do this request:
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code
Where you have to put your client_id and redirect_uri.
Just for information, in redirect_uri field you can insert also
http://localhost
you must be add "+" between scopes like that is "basic+comments+follower_list+likes+public_content+relationships"
OK... so here is my code:
twitterEngine = [[MGTwitterEngine alloc] initWithDelegate:self];
[twitterEngine setConsumerKey:CONSUMER_KEY secret:CONSUMER_SECRET];
accessToken = [twitterEngine getXAuthAccessTokenForUsername:profile.twitterUserId password:profile.twitterPassword];
NSLog(#"Access token: %#", accessToken);
the console shows the access token returned just fine (so it seems to work)
eg. Access token: C8A24515-0F11-4B5A-8813-XXXXXXXXXXXXXX
but instead of accessTokenReceived method being called next on my delegate, it calls requestFailed with a 401. How can I be getting a 401 unauthorized and getting an access token back from the method call?????
xAuth, the process for exchanging a login and password for an access token, is a privilege for applications that verifiably meet Twitter's criteria: desktop or mobile applications that are otherwise unable to provide the entire three-legged OAuth flow. Out-of-band OAuth and custom URI schemes are still preferred over xAuth.
If you've exhausted other OAuth implementations and want to use xAuth, you can contact Twitter through api#twitter.com from an email address directly associated with the account owning the application. Include full details about your application, its user base, links to screenshots of it in action, and a detailed description on why this form of authorization is appropriate for your application. Inquires for xAuth are considered on a case-by-case basis and will not be granted to all applicants.
Implementors of xAuth must not store logins and passwords within their applications -- this is not a drop-in replacement for basic auth or a way to avoid implementing OAuth authentication.
Found the issue... for anyone else that has this problem... Getting your app approved for OAuth is only part of the process. Although it looks like you are done and the twitter page gives you your key and secret... there is one not-quite-so-easy-to-find next step. You must send an email to api#twitter.com and ask them to actually enable it.
That was fun figuring out. :)