Maybe I am stupid or something.
But I have not been able to make the Box API work for me.
I cannot even get the authorization code and the refresh token etc.
I had wanted to write an automated powershell script that would upload to box twice a day from my server, without requiring the user being signed in for box sync.
I cant use the developer token all the time since it only works manually for 60 mins, and cannot be refreshed.
I try to follow the instructions and try to get the url with the id and token data etc that you are supposed to get after hitting "GRANT ACCESS" to the app. but that takes me directly to my folders.
What can I do here?
found my issue
I had to make sure the redirect uri was https:\\localhost and then copy the authorization code from there and proceed to use the API without the developer 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'm working to implement Google Actions, and I've came into this problem.
After successful authentication (Account Linking with OAuth) everything works fine, all of the intents (SYNC,QUERY ec...) are working.
During the test fase I've restarted the server that handles the authentication and the intents (which also holds user sessions our side) so the user session that Google has became invalid (in existent) at our side, so when a new intent is incoming with the access token (that we could say has been expired on my side) the intent fails for authentication error. And here comes the issue:
I've tried to respond with authExpired or even authFailure as described here: https://developers.google.com/actions/smarthome/develop/process-intents#error-responses
but it simply does not work. It seems like until the token does not expire on Google side, I'm not able to make it expire "intentionally". So to make it work we are forced to unlink the action or wait the expiration time than everything works as expected.
It this an intended behavior?
I hope my question was clear, if not I'm here to add more details.
Thanks,
It seems like until the token does not expire on Google side, I'm not able to make it expire "intentionally".
You are correct that this is the current behavior. Generally speaking, we expect developers to use short-lived access tokens where the expiration time is meaningful in requiring those tokens to be granted again.
Developers wishing to enable users to intentionally revoke access (outside of unlinking their account) should invalidate the refresh token provided to Google and continue to return an authFailure when those credentials are presented.
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'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
I have the following situation:
I'm currently attempting to write a Metro-style application, with the ability to let the user sign in with his Google account, and the app requestion several permissions, as Userinfo.profile and Userinfo.email.
For this I'm currently using OAuthv2, and requesting the details worked out fine (after quite some effort and research).
Url used :
const string url = "https://accounts.google.com/o/oauth2/auth?" +
"client_id=" + clientId +
"&redirect_uri=" + "urn:ietf:wg:oauth:2.0:oob" +
"&response_type=code" +
"&scope=https://www.googleapis.com/auth/userinfo.profile+https://www.googleapis.com/auth/userinfo.email" +
"&access_type=offline";
Now the problem is, if I want the user to stay authenticated, I'd either have to do it by saving the token at the clientside, by the user, or find some way to log in using Google, keep the session and check if he is authenticated.
Problem is, I don't know how to perform the latter, and have no idea how to use it.
At the moment, every time I open the application, the user is redirected to the google authorization page, where the whole procedure starts over and over again at each restart.
What I want to accomplish is that if a user logs in, I have some way of identifying him, and not always put a burden on him by re-requesting permissions for the given details.
I looked into OpenID, but I always get
<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/server</Type>
<Type>http://openid.net/srv/ax/1.0</Type>
<Type>http://specs.openid.net/extensions/ui/1.0/mode/popup</Type>
<Type>http://specs.openid.net/extensions/ui/1.0/icon</Type>
<Type>http://specs.openid.net/extensions/pape/1.0</Type>
<URI>https://www.google.com/accounts/o8/ud</URI>
</Service>
</XRD>
</xrds:XRDS>
As a response on this url :
https://www.google.com/accounts/o8/id?openid.mode=checkid_setup&openid.ns=http://specs.openid.net/auth/2.0&openid.return_to=urn:ietf:wg:oauth:2.0:oob&openid.ns.ui=http://specs.openid.net/extensions/ui/1.0&openid.ns.ax=http://openid.net/srv/ax/1.0&openid.ax.mode=fetch_request&openid.ax.required=email,firstname,language,lastname,country&openid.ns.ext=http://specs.openid.net/extensions/oauth/1.0&openid.ext2.consumer=https://www.google.com/accounts/o8/ud?openid.mode=checkid_setup&openid.ns=http://specs.openid.net/auth/2.0&openid.return_to=urn:ietf:wg:oauth:2.0:oob&openid.ext2.scope=https://www.googleapis.com/auth/userinfo.profile+https://www.googleapis.com/auth/userinfo.email
Am I building it wrong ?
If any suggestions, on either how to perform this 'correctly', what I'm trying to accomplish (an integration with google, allowing the user log in using google email, and only if he hasn't authorized the application, ask him to do so, plus finding a way of who he is when logging in for a second+ time), or on how I could do it, please feel free.
Besides, by using the stripped down version of the .Net 4.5 framework, it seems I'm unable to use OpenID libraries as they rely on the full 4.5 .
*Edit* Looking at MSDN this comes up :
To support SSO, the online provider must allow you to register a redirect URI in the form ms-app://appSID, where appSID is the SID for your app.
Does this mean it just isn't possible? Because at google I can only request a key for a domain with http(s):// ?
Have you looked at this? https://developers.google.com/accounts/docs/OAuth2Login
It looks like you are using the Webserver flow and are requesting offline access. This should give you a refresh token after you swap the code. Hold onto this token in your application. If you do an authorization for login as well, you'll get a token back and you can use that to get the userid of the user at Google
Your application should keep track if you have a valid refresh token for a particular user. Then use that token to get the current credentials. You can use tokeninfo enpoint to validate the token. If you have a valid token for the user, there is no need to send them through the code flow to get another refresh token.
If you use the tokeninfo endpoint, the userid field is only present if the https://www.googleapis.com/auth/userinfo.profile scope was present in the request for the access token. The value of this field is an immutable identifier for the logged-in user. Store this and you should have a durable identifier of the user.