I'm only starting to explore what OAuth and I have barely any clue of the related terms.
In a PHP code snippet, I saw :
// Callback can either be 'oob' or a url
$callback='oob';
I'd like to know what oob is?
oob usually stands for "out of band". I would assume that this is to support OAuth responses that come through an unspecified method.
OOB ("out of band") is an alternative to the traditional 3-step process of an OAuth flow (known as 3-Legged-OAuth). The user is not redirected after granting access to a consumer, instead, a code is shown to the user which he needs to manually input in the Consumer App. The difference is outlined in the step 2b below.
An OAuth1a flow:
Step 1: Get a short lived request_token which can be used to access the User Authorization URL.
Step 2: Use the request_token to access and show the User Authorization URL to the user. The user will see a screen where he can accept or decline access; the tipical "Do you want to give App ABC access on your behalf?".
Step 2a (callback url): If a callback_url has been provided, the user will be redirected to that callback URL. The URL will include the parameter oauth_verifier which contains a code, needed for step 3.
Step 2b (callback is oob): If the callback_url is set to oob, the user will not be redirected. Instead, the oauth_verifier code is shown to the user. This must be implemented by the Provider. The user can use this code in the Consumer App, usually a mobile app or any other non-browser based App, to continue to step 3.
Step 3: The oauth_verifier code (and Request Token) is used to get a long-lived access_token. The Consumer can now make calls to the (REST)-API of the Provider using this token in his OAuth calls (the request still needs other OAuth parameters and needs to be signed etc.).
Further info:
Pin based authorization with Twitter API
OAuth1a core specification - Request URLs
Related
I've a React JS app, which makes this request to my back-end API. i.e
window.location = "https://my-server.com" + "/gmail/add_account";
cannot set HTTP headers for window.location see this
this server endpoint redirects to Google OAuth page, which returns a response to my redirect_uri.
def add_account
# no auth headers sent here, because front-end has used window.location
gmail_service = GmailService.new
session[:uid] = params["uid"]
redirect_to gmail_service.generate_authorization_url()
end
def oauth_postback
# session object is {} here
# Since there are no authorization headers, I cannot identify my app's user
# How can I identify my app's user here?
end
The problem I'm facing is that when the OAuth flow sends the response to my redirect_uri it does not return include any authorization header, due to which I'm unable to identify which user of my app has launched this OAuth flow.
I've tried setting up a session variable in the /gmail/add_account endpoint, which works fine. After this endpoint redirects to the OAuth screen, and the Oauth flow sends a response to my Oauth redirect_uri, there my session object is {}.
How can I implement this flow such that I know which user has launched this OAuth flow?
You have basically two options:
the state parameter
The state parameter is part of the OAuth2 spec (and is supported by Google). It's a random string of characters that you add to the authorization URL (as a query parameter), and will be included when the user is redirected back to your site (as a query parameter). It's used for CSRF protection, and can also be used to identify a user. Be sure that if you use it, it's a one-time value (e.g. a random value that you store in your db, not the user's ID).
sessions with cookies
If the user has previously logged in, you should be able to identify them by their session cookie. It sounds like this is the approach you're currently taking, but the session is getting reset.
It's difficult to debug this without knowing more about your stack/code, but a good first step would be just trying to load your callback URL without the redirection to Google to see the session object is still empty. If so, that would indicate an issue with how you've implemented sessions generally and not something specific to this flow.
As a note, based on the code you've shared, I'm not sure how params["uid"] is getting set if you're doing a redirect without any query parameters or path parameters.
Finally, you may consider using a managed OAuth service for something like this, like Xkit, where I work. If you have a logged in user, you can use Xkit to connect to the user's Gmail account with one line of code, and retrieve their (always refreshed) access tokens anywhere else in your stack (backend, frontend, cloud functions) with one API call.
I have implemented the oauth workflow to get access and refresh tokens. Custom classes for OAuthAuthorizationServerProvider and AuthenticationTokenProvider are in place and working.
I'm trying to add Single Sign On functionality (to provide access to third parties through our system), but I'm not sure how it should be done or if I'm missing some pieces.
This is the workflow I would like to implement:
Third party calls /api/Account/ExternalLogin
User gets a login page where they enter the credentials
User is validated through /token call (as if they were trying to get access token)
Third party calls /token with the authorization_code to get the access_token
I'm missing something between step 3 and 4. When you validate a user, you get an access_token but you should redirect the user to 3rd party url with authorization_code so 3rd party system can get the access_token. That's what I do not get.
ok so the workflow is like this ( if I remember correctly! ):
The client will need some sort of setup on your side because you need to know to which URL to send the authorization code.
The user goes to your authorization page and inputs their username / password. If everything checks out, you issue an authorization code and redirect the user back to their URL, passing the code in the URL.
This client URL can look like this: https://www.client.co.uk/authcode_endpoint?code=blah
At this point your job is done for now.
Next, the client will receive this code on their system ( because you called their URL) and can now issue another call to you, to exchange the code for a token and the process repeats.
You send them back to another URL : https://www.client.co.uk/authtoken_endpoint?token=blah
Now they can issue more calls to do what they need to do.
Something like this should be fairly straightforward to do, you have an app to app communication basically. There must be libraries that already provide this kind of workflow for you.
I have a hobby project in mind to use battle.net login. I'm wondering how I can obtain the access token from the API after receiving the authorization code.
This is Oauth flow question rather than a battle.net question.
Currently I can successfully authorize the user for my app which is registered in dev.battle.net and then I try to use the authorization code returned from the battle.net login to obtain the access token by sending a request to https://<region>.battle.net/oauth/token.
However I keep receiving this error:
{
"error": "unauthorized",
"error_description": "An Authentication object was not found in the SecurityContext"
}
I use postman extension to send post requests to that uri. I authenticate my request with my client id and secret. I pass redirect_uri (https://localhost), granty_type (authorization_code), code(the code returned from the previous authorization step). However I keep getting the error above.
I couldn't find much about battle.net online. There are other oauth related help articles but couldn't really find my way.
Wondering if you can help me with this easy stuff. I'm just wondering what I'm skipping here.
Here is the documentation:
https://dev.battle.net/docs/read/oauth
https://localhost is added in my mashery dev account's app settings.
Me again, I resolved this problem after trying almost every combination in the universe:)
Steps to apply:
Don't use the same authorization token for different access token trials, they are not valid
Always use https on every domain you test including localhost, you
redirect_uri must be https as well.
You must use the "basic authentication" in the header of your POST request while requesting the token from the authorization code you obtained from the previous step.
This is one of the most important ones: For requesting token, Pass redirect_uri, client key and secret as POST form parameters to the authenticated request. This is interesting because it's already an authenticated request; why would i need to pass my secret again? Anyways, that's how it works.
Here are the full text:
http://hakanu.net/oauth/2017/01/26/complete-guide-of-battle-net-oauth-api-and-login-button/
This is working prototype:
https://owmatch.me
Thanks.
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.
I'm working with OAuth 2.0 for MVC, found here: http://community.codesmithtools.com/CodeSmith_Community/b/tdupont/archive/2011/03/18/oauth-2-0-for-mvc-two-legged-implementation.aspx
For anyone who's worked with this - I'm confused about the RequestToken. There is a controller implemented that lets you get a request token, which expires in 5 minutes, and you pass that token back in to get an AccessToken. But it never checks the request token for validity - it seems like you can pass in any access token you want to. What is the idea for the RequestToken here - are you supposed to create your own method of storing, referencing, and then deleting that token for those 5 minutes?
Thanks,
Andy
This is all about how OAuth works in conjunction with your application Id, application secret key and valid domains for your application. Here is the process in general
Your application sends a request to the OAuth provider using your application Id and secret along with a callback (return Url).
The OAuth provider gets the request, checks your application Id and secret and validates that the callback url is from a domain that you have specified for your application.
2a. If the callback url is not from a domain that you have specified, then the request is rejected with error.
2b If the callback url is from your domain, it returns a temporary request key to your server.
Given that you received a request key, you send that back to the OAuth provider to get the actual access token for the user.
Now, as to why the request key step is in place, this is to prevent and help protect 'bad people' from attempting to use your application id to falsely authenticate other users. By sending the request token to you (a callback URL that you have approved), the OAuth provider has confidence that the request actually came from your servers.
You most certainly could send any string back instead of the request token, but you would quickly get an error back from the OAuth provider as that request token does not correspond to any existing authentication request from any known application.
Lastly, I am not clear on what you mean by 'validating the request token'? You did not generate the token not probably do not have insight into the algorithm to generate the request token. Given that, I am not sure how you would validate this. If you are concerned about validating the first step, take a look at the Facebook OAuth process. In there, they recommend sending a request key as part of your return Url(as a query string parameter). That request key will come back to your application which you could then use as a validation that, indeed, this is a response to a request that you made. How you store and track that request key is up to you (session, database). In the PHP samples, they use a 'state' variable to track a unique/arbitrary string: Facebook OAuth Server Side Login Example (in PHP)