I'm struggling to figure out how to use my Box authentication tokens to use the Box API. I've built the authentication flow into my app so that I can save away the relevant pieces (access token, refresh token, etc.) to the Keychain. The issue I'm having is that whenever I re-open the app, I can't seem to find an appropriate way to set up my BoxOAuth2Session or whatever to re-use the saved tokens to upload files to Box. Currently, I'm recreating the BoxOAuth2Session with my clientID and secret, and manually setting the accessToken, refreshToken, etc. values on that session. I create a BoxFilesResourceManager, attach this BoxOAuth2Session, and upload a file with uploadFileWithInputStream. This request always fails with a 401. The only way I have been able to upload files to Box is immediately following the login step using the [BoxSDK sharedSDK].filesManager. What is the expected workflow for re-creating the OAuth state to access the API?
A BoxOAuth2Session is bound to an SDK instance. When you access the [BoxSDK sharedSDK] singleton, you are using an instance of the SDK that is already wired up with its own BoxOAuth2Session and manager instances. In normal usage, we recommend using the sharedSDK singleton, so you should manipulate the BoxOAuth2Session attached to this SDK.
One way to do this is to attempt to load a refresh token from the keychain and set the refreshToken property on the OAuth2Session.
[BoxSDK sharedSDK].OAuth2Session.clientID = #"YOUR_CLIENT_ID";
[BoxSDK sharedSDK].OAuth2Session.clientSecret = #"YOUR_CLIENT_SECRET";
// set up stored OAuth2 refresh token
self.keychain = [[KeychainItemWrapper alloc] initWithIdentifier:REFRESH_TOKEN_KEY accessGroup:nil];
id storedRefreshToken = [self.keychain objectForKey:(__bridge id)kSecValueData];
if (storedRefreshToken)
{
[BoxSDK sharedSDK].OAuth2Session.refreshToken = storedRefreshToken;
}
The SDK will automatically refresh the OAuth2 session and acquire a new access token and refresh token on the next API call, so long as the refresh token has not been revoked and is not expired. You may wish to manually trigger a heartbeat call to force a refresh.
We've put together a sample app that demonstrates how to store and load refresh tokens using the keychain.
As a side note, we do not recommend storing the access token on the device since this token is a bearer token; losing this token could allow Mallory to impersonate your app's users.
Related
I followed this tutorial EXACTLY, however
#app.route('/test')
def test_api_request():
if 'credentials' not in flask.session:
return flask.redirect('authorize')
# Load credentials from the session.
credentials = google.oauth2.credentials.Credentials(
**flask.session['credentials'])
drive = googleapiclient.discovery.build(
API_SERVICE_NAME, API_VERSION, credentials=credentials)
files = drive.files().list().execute()
# Save credentials back to session in case access token was refreshed.
# ACTION ITEM: In a production app, you likely want to save these
# credentials in a persistent database instead.
flask.session['credentials'] = credentials_to_dict(credentials)
return flask.jsonify(**files)
However in this part:
credentials = google.oauth2.credentials.Credentials(
**flask.session['credentials'])
The refresh token expires after an hour, with this error:
The credentials do not contain the necessary fields need to refresh the access token. You must specify refresh_token, token_uri, client_id, and client_secret.
But clearly in the flask session the dict object is there:
{'client_id': '<COMMENTED_OUT>.apps.googleusercontent.com',
'client_secret': '<COMMENTED_OUT>',
'refresh_token': None,
'scopes': ['https://spreadsheets.google.com/feeds',
'https://www.googleapis.com/auth/drive',
'https://mail.google.com/'],
'token': '<COMMENTED_OUT>',
'token_uri': 'https://oauth2.googleapis.com/token'}
I believe the google tutorial auto-refreshes the token
Two questions
1) Do i need to manually "refresh" the refresh token? The comment in the tutorial says "Save credentials back to session in case access token was refreshed".. which implies that it's refreshed automatically
2) Is this because the app is still in unverified status?
Looking at the dict, the refresh token is missing:
'refresh_token': None,
You need this token in order to refresh your access token after it expires. The refresh token is only provided in the JSON response if the user saw a consent screen (the one that lists the scopes being requested). If the user has previously approved access, and the scopes haven't changed, the OAuth flow will skip that screen if the user is sent back into the flow, and therefore not return the refresh token.
What likely happened is that during your testing you approved access once, but didn't store the refresh token correctly. Further attempts to approve access didn't return the refresh token, hence your inability to refresh the access token.
To ensure a refresh token is always returned, set the URL parameter prompt=consent in the authorization URL:
authorization_url, state = flow.authorization_url(
access_type='offline',
include_granted_scopes='true'
prompt='consent')
(It's documented in the "HTTP/REST" tab here).
Alternatively, visit and revoke access to your application. The next time you go through the OAuth flow you should see the consent screen again, and get a new refresh token.
I was forcibly trying to expire the Google API OAuth Access Token for the Contacts API.
Here is the general outline of my test:
Get the code:
auth_uri = flow.step1_get_authorize_url()
redirect(auth_uri) code here
Exchange it for the access token:
code = request.GET.get('code')
credentials = flow.step2_exchange(code)
store_for_reuse(key, credentials)
store_for_refresh(key, credentials)
Get a new access token:
credentials_original = get_for_reuse(key)
credentials_for_refresh = get_for_refresh(key)
credentials_for_refresh.refresh(http)
Now, I can verify that the two credentials object have different access token values
credentials_original.access_token != credentials_for_refresh.acesss_token
Surprisingly, I can still make successful API calls with the original access token. Shouldn't the original one expire when the new access token is issued?
Getting a new token does not expire existing tokens. Tokens will be valid for their designated lifespan unless explicitly revoked.
I am new to dot net MVC and I am working on a application which required Box integration, in which user authorizes our application using oauth2 authentication flow.
I get the access token and refresh token and save them to my database for further offline access so that user do not have to authenticate the application again.
Now, I am using Box Windows SDK v2 to get list of files and folders of a user.
Here is the code block by which I am able to get the rot folder of box.
var config = new BoxConfig(clientId, clientSecret, new Uri("http://localhost:49671/CloudBox/Callback/"));
//Pls note, here accessToken and refreshToken are fetched from database
OAuthSession session = new OAuthSession(accessToken, refreshToken, 3600, "bearer");
BoxClient client = new BoxClient(config, session);
BoxFolder boxFolder = client.FoldersManager.GetInformationAsync("0").Result;
Everything is fine upto this point.
Now when the access token expires (as it is valid only for 3600 seconds), and I try to get the root folder again, Box SDK refreshes access token and refresh token automatically without telling me. and provides me the root folder object.
At this moment I got the root folder, but I am not aware that Box SDK has updated the access token and refresh tokens. Still I have old access token and refresh token in my database. They are not updated. And I am lost. Now I am left with those old invalidated access token and refresh token.
Pls help. How do I know that Box SDK has updated access token and refresh token ? so that I can update them in my database for future use.
It would be nice, if you can provide a working sample MVC application which stores the access token and refresh token. You can provide the code blocks which needs to be placed in controller. I hope, I will be able to integrate them.
Thanks in advance.
You could use the events triggered by Box.V2 after refreshing the token:
SessionAuthenticated : Fires when a new set of auth token and refresh token pair has been fetched
SessionInvalidated: Fires when the authenticaiton session is invalidated
We have Azure ACS configured to issue JWT that is valid for 15 minutes. Once the user is logged-in to the web application (MVC), the user will use the token to access resources on another server (WebAPI). The WebAPI server would then validate that token.
So, is there any way to renew the JWT somehow without interrupting user's work on the web app? We don't want to popup a window and ask the user to sign in again.
Thanks!
If you are using Active Directory Authentication Library (ADAL) for .NET, then it includes a token cache. Per this blog post:
One last thing I’d highlight at this point is that every time you get a token from the authority ADAL adds it to a local cache. Every subsequent call to AcquireToken will examine the cache, and if a suitable token is present it will be returned right away. If a suitable token cannot be found, but there is enough information for obtaining a new one without repeating the entire authentication process (as it is the case with OAuth2 refresh tokens) ADAL will do so automatically. The cache is fully queryable and can be disabled or substituted with your own implementation, but if you don’t need either you don’t even need to know it’s there: AccessToken will use it transparently.
ADAL.NET is available on Nuget here: https://www.nuget.org/packages/Microsoft.IdentityModel.Clients.ActiveDirectory/
If you aren't using ADAL.NET, provide more info, such as:
What library you are using
What is ACS on top of, AD FS or Azure Active Directory
We use ACS + ADAL and there seems to be no clever way to refresh the token. Even if the ExpiresOn Time on the Token inside the Cache is due the AcquireToken always returns the stale cached token. We cache the token ourself, so this code is only invoked when the ExpiresOn is due.
I ended up with this dirty hack:
var authContext = new AuthenticationContext(ServiceInfo.AcsUrl);
if (authContext.TokenCacheStore.Count > 0)
{
authContext.TokenCacheStore.Remove(authContext.TokenCacheStore.First());
}
result = authContext.AcquireToken(acsRealm, allProviders.First());
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. :)