We have a desktop app (Delphi XE2) that gets an oauth request token from Intuit and fires off the URL call to Intuit where the user authorizes our app. This half of the oauth dance seems to be working.
The problem we are running into is getting the Access Token and Access Token Secret. We never seem to get it.
Details:
This is for QuickBooks v3 API.
We have a web service setup to handle the callback whose URL we pass along when we make the call to get with request token to https://appcenter.intuit.com/Connect/Begin
That opens the Intuit web page with our test company and our app listed. When we grant access to our app from the Intuit site the web browser is redirected to our callback URL and that contains an oauth token (which I'm not really sure is our access token) but we never get the access secret. That's the missing thing for us.
Is the token we are getting in the callback our access token?
If so how do we get the access secret? Is that token another token to be used to make another call to https://oauth.intuit.com/oauth/v1/get_access_token where we would obtain our access token and secret?
I tried using the token returned to our callback URL as a token for the "get access token" url and that gave me unauthorized errors.
If the token returned to our callback URL is not the access token where/how the heck do we get it?
Any help or direction is appreciated.
UPDATE:
So, it turns out I was missing one entire step of the OAuth dance.
After the user authorizes access and that passes the original request token and a verifier key to our web service. That verifier key is used with the original token in yet another call to Intuit to get the access token and access token secret.
Cheers!
TJ
The initial callback returns to you a request token, which you then have to send back to Intuit via the get_access_token URL to get an access token and secret.
Intuit instructions:
Implement OAuth in Your App
The OAuth spec it refers to is RFC 5849.
You can refer the sample V3 APP.
https://github.com/IntuitDeveloperRelations/QuickbooksV3API-Java
To be specific, please refer
OAuthController.java and OAuthHelper.java
Thanks
Related
I have a back-end processor, (imagine a chron job once a day generating reports), that needs to integrate with a third-party system. Their APIs only support the "Authorization code" grant type. The problem is I can't even fill out a request for a token as I don't have a redirect_uri (no website), and I definitely don't have a user of any kind. I'll just have the OAuth clientId and secret I provisioned via their developer portal, (Mashery), for my back-end report processor app.
I want to use the "Client credentials" grant type/flow since I'm just a back-end service.
Is there any way to fake this or hack it so my little back-end service can somehow work with authorization code flow?
Thanks in advance
No, there is no way to hack it. Client credentials only authenticate the client. A token issued for client credentials have no information about the user. If their API needs information about the user (you probably get information only about your user), then you need to have a token issued with Code Flow.
What you can do is to generate the OAuth token yourself. E.g. you can use oauth.tools to perform a Code Flow with their Authorization Server, or you can perform the flow from browser with a dummy redirect URI (e.g. http://localhost), the get the code returned from authorization request and perform a token request from curl.
Once you have an access and refresh token you can hard code them in your script (or read them from an env variable or file, etc). You can then call the API as long as the access token is valid, and use refresh token to get a new access token when it expires. You will not have to perform a new Code Flow for as long as the refresh token is valid.
Lets say I have created my own application. We have react front end and RESTful API as backend and we are using Google OAuth for Authorization of our users. Front end is making calls to the APIs. Front end uses Authorization Code Flow of OAuth. After getting access token from Google OAuth server, front end uses this token to make calls to my backend.
Now Malicious user will get my API's URL, other information required for REST API from Chrome Network tab and can call directly to APIs with access token.
Questions:
How will my REST API know from where the request is coming?
Also how it will validate the access token?
Is it possible once User got all information about my REST API, it can call directly with fake access token?
I have look into the diagram for Authorization Code Flow. Below is the link.
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-app-types
But how will web api validate the token?
Please guide me if I am lacking some information.
Google's OAuth server will issue your front-end a JSON Web Token (JWT). This token is singed by Google private key. Your API needs to:
Obtain Google's public key and
Verify the signature of the JWT.
If that is valid, the token originated from Google. If not, it didn't come from Google or was tampered with.
After this, your API needs to do a few additional checks:
Check the expiration time and see that it's not in the past. This can be found in the exp claim.
Check that the token is not only from Google but for your API. This can be done by looking at the aud (audience) claim and seeing that it's for you.
Check when the token was issued, and ensure that it's not in the future. The issuance time is in the iat claim.
Check that you should start using it already, and there wasn't some sort of embargo on the usage period. This will be indicated in the not-before claim (nbf).
Check that the type of token is an access token (as opposed to an ID token).
(You can find a longer more detailed description in this howto.)
If you do these things, you can be sure that Google issued the token and that it was intended for your API. It does not indicate to your API that the caller was your front-end. The reason is that the token is an "bearer token", meaning the token is bound only to the one that bears or presents it. To ensure that only your app provides the token, you need it to prove possession of a private key. This is not possible when using Google as your token issuer (to my knowledge).
My question is basically how do my rest api validate integrity of the token. I found the link: https://developers.google.com/identity/sign-in/android/backend-auth
A quick overview of the problem.
I have a client application that will use IDS to authorise access to a google service on behalf of the end user.
However, the client application isn't, itself responsible for talking to google. There is a Server app that does some magic with the user's data on his behalf.
Now, if I understand things correctly, the server app will use the Access Token supplied by the client app to talk to google. What happens when that access token expires? As I understand it the client application is expected to use the refresh token to as for a new access token.
Is there an issue with the server using this refresh token to update the access token? What flow am I supposed to use to make this magic happen?
A server using a refresh token to get a new access token is a valid use case.
If you're working with OAuth you can use the Client Credentials or Resource Owner flows to use refresh tokens, otherwise for OpenID Connect you'll need to use Authorization Code or Hybrid.
I am following this tutorial about OAuth2.0 https://developers.google.com/youtube/v3/guides/authentication
It looks quite clear how OAuth2.0 works. But I have a bit confusion at the access token part.
After obtaining an access token for a user, your application can use
that token to submit authorized API requests on that user's behalf.
The API supports two ways to specify an access token: Specify the
access token as the value of the access_token query parameter:
www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN
if someone acquired this access token during the url transferring they can access this protected resource right?
How the server know if the request is coming from the client initially requested the access token?
UPDATE:
after reading this post Are HTTPS headers encrypted? my confusion is cleared. I thought query string is not encrypted during transmission in the network.
Generally I think the consensus is that OAuth 2.0 is a server side technology and all access tokens and communication should be transmitted using SSL as the bearer tokens need to be kept as secure as possible.
Also, you need to know that there are 2 types of flows in OAuth 2.0
i) Implicit grant flow - This is the flow where the user logs in to the service provider and his browser gets the access token. Say you have X.com and Log in via Facebook. Once the user keys in his FB credentials, the access token is sent to his browser.
ii) Authorization Code flow - In this flow (consider the above situation again), facebook will pass an authorization code to the user's browser. If anyone, somehow, intercepts the authorization code there is nothing he can do. An authorization code can be exchanged for an access when passed with valid client credentials. So, when the user logs in, his browser gets an authorization code which is passed to your server at X.com. from there you would hit the code-token exchange endpoint provided by FB and get the access token returned to your server!
Authorization code flow adds another layer of security, where the access token is visible only to the client + server and not to the user agent. And as you figured out yourself, the token is passed via HTTPS.
I am trying to impliment Oauth for my webapplication for google.I am worked upon a POC and it working fine but i have a confusion and not sure how best it can be achieved.
I am using scribe java API for Oauth.
here are the steps i am performing.
Getting request token from Google.
Redirecting user to Google to authenticate them self and authorize my serivice to access his/her few details.
get Access Toekn from google by providing request token and verification code given by google.
Accessing user info once google provide Access token.
now my main confusion is at step no 3, since i am working on a web-application so it will be a 2 step process.
Redirecting user to google
Handling back google redirect.
In order to get an Access token i need to provide same request token which i got at step1 else my request being rejected by the user.
The request token contains 2 things
Toekn -->which is based on the registered application so not an issue
Secret-->This is always being a random string so it should be same when asking for access token
that means i need to store this secret either in my session or some where so that i can access this secret when user is being redirected back to my application.
My confusion is,since in order to save it in session i have to create a unique key and some way to access it in the other action class which will handle Google Redirect back how can i achieve this since at a given time so many user can ask to login using google.
any help in this regard will be much appriciated.
Thanks in advance
When you receive the request token + token secret, use the request token as the unique key of your session to store the token information. After the authorization process, in the callback url, you have access to the request token (it's one of the parameters passed to the callback url). Using this parameter as the session key, you can restore the token information from session, including the token secret, and use it to sign your request for changing the request token for access token. After receiving the access token, a new token secret is returned to you and you can delete the old one from session.
how can i achieve this since at a given time so many user can ask to
login using google
This is not of any problem because for every single user on your site, you are given a different request token.