I'm working on a project and a new Beats Music API library for Clojure, but in my testing I'm finding it difficult to get write access authentication, but read-only user authentication works fine.
In testing my library I set up a HTML page to do the OAuth and get the OAuth code and then feed that code in to my library to fetch the actual authentication token. The first part works flawlessly, the second part has the dreaded "Developer Inactive" error:
URL: /oauth/token
PARAMS: client_secret, client_id, redirect_uri, code, grant_type=authorization_code
METHOD: post (application/x-www-form-urlencoded)
I've double checked my redirect_uri is the same as defined in my app settings and is the url of the HTML page I generated the code with. I even checked with the support folks to double check that my application wasn't throttled or something, but that took too long and I made a second application and had the exact same results. I've looked at other support questions like this and nothing has helped, so unless I'm missing something in my auth request, my only other thought was that my user account is still on it's 14-day trail and maybe that is affecting my auth token in some way?
Any ideas or suggestions would be greatly appreciated.
From https://developer.beatsmusic.com/docs/read/getting_started/Client_Side_Applications
"The scope of an access token using the implicit flow is limited to read only since client side applications cannot keep a secret. You'll need to request the authorization grant flow via the Web Server Authentication for write permissions, such as updating a playlist."
I hope this helps.
As #jsd pointed out in a comment on my question, there was a typo in the url endpoint. The correct endpoint is (which I had in the other function and that's why it was working correctly):
/oauth2/token
Related
Using the App Console, I am generating an Access Token for use by my java application.
Why is my access token expiring? It worked yesterday but today I get the below error.
How do I get a permanent token for my application to use? (Usage is similar to a "Google Service Account" that generates a permanent token.)
Exception:
InvalidAccessTokenException
{
"error_summary": "expired_access_token/...",
"error": {
".tag": "expired_access_token"
}
}
UPDATE 2022 12 02:
Thanks for the below information and links. After about 5 hours of working on wrapping my brain around the concepts and the example code, I finally got something working by doing the following:
(1) Using the example code and manual process at https://github.com/dropbox/dropbox-sdk-java/blob/main/examples/examples/src/main/java/com/dropbox/core/examples/authorize/ShortLiveTokenAuthorize.java I obtained an auth code.
(2) I then wrote java code to post the auth code to the https://api.dropbox.com/oauth2/token end point and receive tokens including the refresh token.
(3) I then wrote code to post the refresh token to the same end point to receive an access token.
It appears I can hold on to the refresh token and repeat step 3 to get access tokens each time.
HOWEVER, I must be missing something here.
This is WAY too much extra work that should be done either by the App Console and/or the SDK.
Also, it seems to me that a “Client Credentials Flow” should be available in the API and SDK.
Your thoughts?
Dropbox is in the process of switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.
Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. You can find more information in the OAuth Guide and authorization documentation.
The official Dropbox Java SDK can actually handle the process for you automatically, as long as you supply the necessary credentials, e.g., as shown retrieved in the examples here.
I'd like to implement a Facebook authentication that does not perform traditional oauth redirects. It doesn't play nicely with my single-page-application and GraphQL API.
On the JS side, I can invoke FB.login to trigger a dialog for the user to login. If this is successful, I receive an object containing an accessToken and a signedRequest.
signedRequest can be decoded on the server and it spits out a code for me. I can use code with /oauth/access_token to get an accessToken.
However, I already had the accessToken this whole time from the FB.login response. So my question is: is there any point of me decoding the signed request, if I had the access token this whole time?
Bonus: Why does the FB API provide a signed request in the first place, and why does the oauth redirect by default forward the code and not an accessToken?
Yes, you can use the token you got from the client-side login, directly on the server.
It might however be a short-lived one, whereas the server-side login flow should give you a long-lived one right away. If you only need to perform API calls while the user is active on your page, the short-lived one will probably do. (And it could still be exchanged for a long-lived one with a server-side API call, https://developers.facebook.com/docs/facebook-login/access-tokens/refreshing)
Why does the FB API provide a signed request in the first place
It also contains a bit more info, that might be useful for a client-side app (user id, token expiry, externally passed in data in case of the old “Canvas” type apps), and might save on one additional API call to get that kind of info. https://developers.facebook.com/docs/reference/login/signed-request/
and why does the oauth redirect by default forward the code and not an accessToken?
General security measure. The token contained directly in the return URL, could easily be stolen by 3rd-party scripts that might be embedded on that page (ad servers etc. can get hacked from time to time, too), or leaked as part of the HTTP referrer.
The code parameter requires your app secret for the API call that exchanges it for a token, so if the code were to leak in any such way, whoever else got their hands on it, can’t do anything with it.
We are trying to support the 'traditional' Account Linking flow as it seems the most general purpose, gives us a chance to surface T&C's, and we thought would be most bedded in.
But testing in the Assistant mobile app for starters, it fails for most users in our Actions app in Dev - After the user sees the Google-driven pop-up in the Assistant app with the "LINK ACCOUNTS" option - They tap that option, and our authorization screen does not appear.
Actions support have had a look at our Account Linking config and can't see any problems.
A couple of test users with newer Android phones DO see our Authorization screen, but the majority do not.
If we test the Authorization URL by pasting into a browser on the same device - It always displays just fine.
What is strange - If we look in our web server logs during the failed cases, the only hits we are seeing are to our 'TOKEN URL', whereas my understanding is a newly linking user should hit our 'Authorization URL' before ever hitting Token.
The successful cases DO hit our Authorization URL first, as expected.
Feel free to pipe up if anyone can answer ANY of the following:
Any ideas what could be causing problems here?
Or ways we might investigate deeper?
Does an app need to be in Alpha testing, or anything like that before Account Linking works?
Is it normal/expected to hit the Token URL for a user that has never successfully linked accounts?
Can anyone confirm what the Token fetch response should be in that case? (Maybe we are not responding in a way that satisfies the other end)
Does anyone have a dummy/HelloWorld Account Linking web end-point we could test against? (Geeze that would be handy for the developer community!)
I don't know exactly what is going on, but there are a couple of hints about what is happening and what avenue to investigate. I'm going to assume you're doing Account Linking with OAuth only. If you are doing a combination of "Google Sign In for Assistant and OAuth", that might change some things. To address some of your questions:
What could cause the Assistant to go to the Token Endpoint instead of the Auth endpoint?
It wouldn't go to the Token Endpoint unless it already had a Token. I could think of a few possible scenarios:
If it was going to Auth, getting a token since it was already authorized, so no window would pop up. (But you indicated it isn't going to that page.)
If the account in question is already authorized to the project via some other means. You can check https://myaccount.google.com/permissions to see if it is already authorized.
If you had tested it with this account previously and it has a token from then. If so, it should be listed at https://myaccount.google.com/permissions. Probably.
If you're not using the account you think you're using on the device in question.
How to investigate this?
Once you double-check some of the more obvious things (using the right account?):
Look at what is being sent to the Token endpoint
Does the token look familiar? Is it the same between calls? Same between different accounts?
Do you log tokens being issued? Can you?
What about the other information sent along with the token such as the client_id and client_secret?
Does it need to be in Alpha?
I'm not sure. Last I checked, it did not. I do think that it no longer works in the simulator, which is annoying, but doesn't require being in Alpha.
It does make it a little more difficult to check, however, since there is no Directory page that can tell you if the account is already linked. You'll need to go to the list of linked apps for the account to remove your app if it is: https://myaccount.google.com/permissions
Is this normal?
I wouldn't think so. It shouldn't hit the Token Endpoint unless it has an auth code or refresh token to exchange. It has to have that code/token from somewhere.
How should you respond?
If you get an auth code or refresh token that is invalid, or any of the other information provided at the token endpoint doesn't match what it should, you must return HTTP error code 400 "Bad Request" and include as the body the JSON
{"error": "invalid_grant"}
This should force it to go through reauth with the user.
Is there a public test server?
Auth0 isn't exactly public, but is free for basic use, and well suited for test purposes.
I am playing around with IBM Cloud Functions (OpenWhisk) and trying to setup authentication through OAuth with Facebook as the provider. I have setup an app with Facebook, I am able to successfully connect with this and fetch my token and I am able to verify this by fetching basic profile information (name and userID).
My problems starts when I enable OAuth in the IBM Cloud Functions API. I get a HTTP code 500 back from the call with very little information about what actually went wrong.
{"code":500, "message":"Oops. Something went wrong. Check your URI and try again."}
The only thing that is stated in the dashboard is:
You can control access to your API through the OAuth 2.0 standard. First require an end user to log in via IBM Cloud App ID, Facebook, GitHub, or Google. Then include the corresponding OAuth token in the Authorization header of each API request. The authenticity of the token will be validated with the specified token provider. If the token is invalid, the request will be rejected and response code 401 will be returned.
With this information I got that I need pass the token with the Authorization header. My best guess is that the call fails somewhere when the token is being validated.
I am using Vue and Vue-axios to perform the API call. My current call looks like this:
this.$http.get(API_URL+"?user_id="+localStorage.user_id,{headers :{'authorization':localStorage.token}}).then((response) => {
console.log(response);
});
I have tried adding bearer/Bearer or token/Token in front of the token (some posts I read indicated that you should do this), but this had no impact on the response.
If I disable the OAuth authentication from the Cloud Functions side, the code above works and correctly retrieves the data (with or without the header option).
From the Chrome Dev tools it looks to me like the token is added correctly to the request, since the request headers have the Authorization header with the token.
I am not that familiar with OAuth or IBM Cloud Functions, so the problem might have a very easy fix. However, I am unable to find documentation which clearly shows me how I am supposed set this up. I am also unable to find any logs or more information about what actually fails here. Am I missing something obvious here?
Kjetil
I'm working on my own project (mostly for education) and I need to create authentication & authorization mechanism for my REST service.
I've read a few articles & some good answers here, but i still can't understand the process completely. So from my point of view the simple process of authentication & authorizationshould look simething like this:
User enters login and password in the web browser. But is it safe to pass credentials as regular parameters in the url? Even after client-side encryption.
If valid credentials were passed REST service returns some token, which is unique for each user. This token should be passed in http header for every request and define user permission (i assume SSL is mandatory in this case). But where user should store this token? Is is approach safe?
Each request should be passed through filter that compares user permission (fetched from token in header) and resource permission. In case access should be denied 401 error will be returned.
So that's how I see solution, but it doesn't seems secure and reliable so far. Any corrections/advises/suggestions/links ?
Thanks in advance for everyone!
Okay, I've spent some time investigating my problem and here is the solution i found
Thanks to Suketu for comment! Credentials could be passed in the url using POST & HTTPS.
It's ok to add custom token to every request, but also cookie-based auth is acceptable. What about my question: there 2 types of HTML5 Web Storage
1) window.localStorage - stores data with no expiration date
2) code.sessionStorage - stores data for one session (data is lost when the tab is closed)
Useful links
If you want to get more information about cookie-based vs token-based auth you can dive into AngularJS article (https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/)
IMHO good question of how to generate tokens & related questions (https://security.stackexchange.com/questions/19620/securing-a-javascript-single-page-app-with-restful-backend)
A guide for web storages (https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage#localStorage)
And a guide for java developers how to create REST service auth(http://howtodoinjava.com/2013/06/26/jax-rs-resteasy-basic-authentication-and-authorization-tutorial/)
UPDATE
A little bit more up to date article about auth with jax-rs 2.0 and jersey (http://www.theotherian.com/2013/07/creating-resource-filters-with-jersey.html)
Hope this will be helpfull for someone :)