Chrome.identity works perfectly without asking for credentials - google-chrome

I have implemented the chrome.identity launchWebAuthFlow to authenticate users of a web extension against an oauth2 provider and the entire flow works perfectly, I receive the access token back in the redirect URL, I extract the token using a regex and then it is valid and accepted to query the APIs.
However, I do not understand why it does not prompt anymore for credentials when I launch again the launchWebAuthFlow. Instead, it retrieves another (valid !) token in the background. Don't get me wrong, I like this, and I prefer it works in the background, but I just don't understand how. Even after clearing all cookies and local data, when I launch the launchWebAuthFlow again it just works in the background without asking for credentials...where are they stored?
Also, not sure if that helps, but my flow is the following:
extension ->oauth2 server->azure ad SSO->enter credentials->redirect to extension
So the real authentication is managed by Azure AD. However, even when I'm signed out from Microsoft, the extension keeps getting a valid auth token when the below code is triggered and without asking for credentials...so the credentials must be stored somewhere...
chrome.identity.launchWebAuthFlow(
{
url: dev.identity_url(),
interactive: true
},
function (responseWithToken) {
// the access token needs to be extracted from the response.
console.log(responseWithToken);
let token = responseWithToken.match(/(?<=access_token=).*(?=&token_type)/);
token = token[0];
chrome.storage.local.set({ "auth-token": token }, function () {
console.log(`Access Token has been saved: ${token}`);
});
}
);

Related

U2F with multi-facet App ID

We have been directly using U2F on our auth web app with the hostname as our app ID (https://auth.company.com) and that's working fine. However, we'd like to be able to authenticate with the auth server from other apps (and hostnames, e.g. https://customer.app.com) that communicate with the auth server via HTTP API.
I can generate the sign requests and what-not through API calls and return them to the client apps, but it fails server-side (auth server) because the app ID doesn't validate (clients are using their own hostnames as app ID). This is understandable, but how should I handle this? I've read about facets but I cannot get it to work at all.
The client app JS is like:
var registerRequests = // ...
var signRequests = // ...
u2f.register('http://localhost:3000/facets', registerRequests, signRequests, function(registerResponse) {
if (registerResponse.errorCode) {
return alert("Registration error: " + registerResponse.errorCode);
}
// etc.
});
This gives me an Error code 5 (timeout error) after a while. I don't see any request to /facets . Is there a way around this or am I barking up the wrong tree (or a different forest)?
————
Okay, so after a few hours of researching this; I'm pretty sure this fiendish bit of the Firefox U2F plugin is the source of some of my woes:
if (u.scheme == "http")
if (url2str(u, true) == url2str(ou, true))
return resolve(challenge);
else
return reject("Not matching appID");
https://github.com/prefiks/u2f4moz/blob/master/ext/appIdValidator.js#L106-L110
It's essentially saying, if the appID's scheme is http, only allow it if it's exactly the same as the page's host (it goes on to do the behaviour for fetching the trusted facets JSON but only for https).
Still not sure if I'm on the right track though in how I'm trying to design this.
I didn't need to worry about facets for my particular situation. In the end I just pass the client app hostname through to the Auth server via the secure API interface and it uses that as the App ID. Seems to work okay so far.
The issue I was having with facets was due to using http in dev and the Firefox U2F plugin not permitting that with JSON facets.

VimeoUpload not re-authenticating After Deletion of App Access on Vimeo.com

I was able to connect and upload videos using the library but when I deleted the app connection on Vimeo.com (as a test) the app didn't authorize again.
the upload looks like it's working but nothing is uploaded as the app is no longer connected.
I deleted the app on the phone and restarted but it still won't re-authorize the app.
This comes up in the output:
Vimeo upload state : Executing
Vimeo upload state : Finished
Invalid http status code for download task.
And this is in OldVimeoUpload.swift: ( didn't include the actual access code!)
import Foundation
class OldVimeoUpload: VimeoUpload
{
static var VIMEO_ACCESS_TOKEN :String! // = "there's a string of numbers here"
static let sharedInstance = OldVimeoUpload(backgroundSessionIdentifier: "") { () -> String? in
return VIMEO_ACCESS_TOKEN // See README for details on how to obtain and OAuth token
}
// MARK: - Initialization
override init(backgroundSessionIdentifier: String, authTokenBlock: AuthTokenBlock)
{
super.init(backgroundSessionIdentifier: backgroundSessionIdentifier, authTokenBlock: authTokenBlock)
}
}
It looks like the access token number is commented out. I deleted the 2 forward slashes to see if that would fix it but it didn't.
I spoke too soon.
It sounds like you went to developer.vimeo.com and created an auth token. Used it to upload videos. And then went back to developer.vimeo.com and deleted the auth token.
The app / VimeoUpload will not automatically re-authenticated in this situation. You've killed the token and the app cannot request a new one for you. You'll need to create a new auth token and plug it into the app.
If this is not accurate and you're describing a different issue let us know.
If you inspect the error that's thrown from the failing request I'm guessing you'll see it's a 401 unauthorized related to using an invalid token.
Edit:
Disconnecting your app (as described in your comment below) has the same effect as deleting your auth token from developer.vimeo.com.
Also, VimeoUpload accepts a hardcoded auth token (as you see from the README and your code sample). It will not automatically re-authenticate, probably ever.
If you'd like to handle authentication in your app check out VimeoNetworking or VIMNetworking. Either of those libraries can be used to create a variety of authentication flows / scenarios. Still, if a logged in user disconnects or deletes their token, you will need them to deliberately re-authenticate (i.e. you will need to build that flow yourself). In that case, the user has explicitly stated that they don't want the app to be able to access information on their behalf. It would go against our security contract with them to automatically re-authenticate somehow.
Does that make sense?

What does "error_description:access_denied" mean in BoxServerException

I ma trying to refresh my access token using the refresh token I have but I get following exception:
com.box.boxjavalibv2.exceptions.BoxServerException:
{"error":"access_denied","error_description":"Access denied"}
Please tell me what could be wrong with my request and why I am getting access_denied
If I send invalid refresh token, then I get
Caused by: com.box.boxjavalibv2.exceptions.BoxServerException:
{"error":"invalid_grant","error_description":"Invalid refresh token"}
I want to know the reasons for access_denied.
------------------- relevant code ------------------
BoxOAuthRequestObject requestObject = BoxOAuthRequestObject.refreshOAuthRequestObject(refreshToken, clientId,
clientSecret);
try {
// Authenticate with the new token
BoxOAuthToken boxOAuthToken = client.getOAuthManager().refreshOAuth(requestObject);
Not really sure what's going on without more information of your code.
One thing is that the sdk does auto-refresh the OAuth token. So basically you don't need to refresh it yourself. Please check https://github.com/box/box-java-sdk-v2#authenticate
I've received that error when attempting to call API methods that accessed the "Manage an enterprise" methods, while my application was defined as "Read and write all files and folders".
Make sure you set the appropriate checkbox at the application level.

Calendar API Response with '403: Daily Limit Exceeded' - Google Chrome Extension

I started with an little application for showing some relevant information to our developer team, which is collected from different sources. Like google calendar, our project backoffice, an openarena server-logs etc.
I started with an web application, but then decided to switch the project to an chrome extension. Now i already had the google calendar integration up and running using the V3 Javascript(alpha) Client-Lib. This wasn't working anymore because i had to change the OAUTH dance, from the one for web-apps, to the one for packaged/installed apps.
For this i followed the tutorial (It's my first extension.) http://code.google.com/chrome/extensions/tut_oauth.html and got the OAUTH dance working again. Now i'am trying to request my calendar-data from the google api using the signedRequest-Methode from the tutorial, but alway receive the response "Daily Limit Exceeded. Please sign up" (Api Console shows i haven't performed any request).
Maybe someone has an idea what i am doing wrong here, because i tried everthing i could think about. Thanks in advance, Florian
Code -
manifest.json:
{
"name": "MIS",
"version": "0.1",
"description": "Monitor Information System",
"background_page": "background.html",
"browser_action": {
"default_icon": "img/mis/icon.png",
"default_title": "Mis"
},
"permissions": [
"tabs",
"https://www.googleapis.com/",
"https://www.google.com/"]
}
background.html:
...
oauth = ChromeExOAuth.initBackgroundPage
({
'request_url':'https://www.google.com/accounts/OAuthGetRequestToken',
'authorize_url':'https://www.google.com/accounts/OAuthAuthorizeToken',
'access_url':'https://www.google.com/accounts/OAuthGetAccessToken',
'consumer_key': 'anonymous',
'consumer_secret': 'anonymous',
'scope': 'https://www.googleapis.com/auth/calendar',
'app_name': 'Mis'
});
...
main.html Methode call:
function performCalendarEventsRequest(calendarId)
{
var requestUrl = 'https://www.googleapis.com/calendar/v3/calendars/'+calendarId+'/events';
var request = {
'method': 'GET',
'headers': {
'GData-Version': '3.0',
'Content-Type': 'application/atom+xml'
},
'parameters': {
'alt': 'json'
},
'body': 'Data to send'
};
oauth.sendSignedRequest(requestUrl, calendarEventsRequestCallback, request);
}
Since your consumer key and secret are both set as anonymous you are not identifying your application in any way.
You can either replace these with the Client ID and Client secret values respectively, which can be found on the API Access tab on your projects page in the API Console, or you can pass the API key (found just under the auth tokens on the same page) using an additional key parameter.
This is the same for most Google APIs.
Source: http://code.google.com/apis/calendar/v3/using.html#APIKey
I know this is an old question but I was stuck in the same error using the PHP implementation (Beta) of the API (2016-01-06), because I initially thought the setAuthConfigFile was all it was needed:
$client = new Google_Client();
$client->setApplicationName('MyCalendarAppName');
$client->setAuthConfigFile(APPPATH.'client_secret.json'); //file downloaded from GDC:
// https://console.developers.google.com/apis/credentials?project=YOUR-PROJECT-ID
$client->addScope(Google_Service_Calendar::CALENDAR_READONLY);
$service = new Google_Service_Calendar($client);
The error was not really due to a "daily limit" of requests but to the fact that I (owner of the Google account) hadn't explicitly given access permissions to the calendar. This is how to do it:
access the URL returned by the createAuthUrl() method (which can be invoked before calling the service);
a "Deny" and "Allow" form for accessing the calendars shows up – press Allow;
a code is returned – copy&paste this code to the authenticate($code) method and voilá, no more 403: Daily Limit Exceeded errors.
For doing this, just use the following lines before invoking the service:
//$client->createAuthUrl();
// - invoke the method above one time only: returns a URL with the "Allow" form
// which will give the code for authentication
$client->authenticate('YOUR_CODE_GOES_HERE');
$service = new Google_Service_Calendar($client); //invokes the Calendar service
However, this will allow a one time access to the calendar. If you try this twice, you get:
Google_Auth_Exception: Error fetching OAuth2 access token, message: 'invalid_grant: Code was already redeemed.'
Meaning that a token is needed to reaccess the calendar with the reedemed code. This token is returned by the authenticate method and can be assigned to the client through the setAccessToken method:
//get the access token you previously stored or get a new one to be stored:
$accessToken = $client->authenticate('YOUR_CODE_GOES_HERE');
//after the if-else blocks...
$client->setAccessToken($accessToken);
//refresh the token if it's expired
if ($client->isAccessTokenExpired())
$client->refreshToken($client->getRefreshToken());
The goal is to reuse that access token repeatedly (implicitly also reusing the redeemed code) and only invoke a refreshToken when the token expires. Google's quickstart creates a specific file for storing this token (calendar-php-quickstart.json) and only uses the authenticate method when the token is not found in that file. I.e. the setAccessToken is the only Client authentication method (besides the setAuthConfigFile) that needs to be used in subsequent requests.
I only fully understood this OAuth 2.0 logic by going through these errors and since this question attracted so many people already, perhaps this may help others...

How can I enable the file upload permission?

I'm trying to upload images generated in my Flash application to an album on Facebook. This was working earlier in the year, but revisiting the code I now get the following OAuthException:
(#324) Requires upload file
I am using the most recent version of the ActionSccript Facebook API. The setup works like this:
First I do the authentication check with PHP to ensure users have granted permission before having to wait for the Flash to load. I'm requesting the publish_stream and user_photos permissions. The access token comes back correctly.
Once the user is authenticated the Flash is loaded and performs its own initialisation, passing fileUpload=true as part of the init object:
var initObject:Object = {
channelUrl : "myChannelURL.html",
fileUpload : true
}
Facebook.init(
'myAppID',
myCallbackFunction,
initObject,
myAccessToken
);
This seems to work as expected, the callback receives the uid of the current user.
At the end of my application I POST a Bitmap object to a predetermined album:
Facebook.api(
albumID+"/photos",
onImagePost,
{
message:"",
image:new Bitmap(myBitmapData),
fileName:''
},
URLRequestMethod.POST
);
At this point Facebook returns a 400 response:
"error": {
"message": "(#324) Requires upload file",
"type": "OAuthException"
}
What more do I need to do to ensure that this permission is being included?
It turns out that this was not a permissions error at all. Since I last deployed this code Facebook have tightened up their restrictions a bit, and the fileName parameter passed as part of the api call can no longer be an empty string. Simply passing any old text as a file name fixes the problem.
Facebook.api(
albumID+"/photos",
onImagePost,
{
message:"",
image:new Bitmap(myBitmapData),
fileName:'FILE' // required to be non-empty
},
URLRequestMethod.POST
);
Im not sure if this is a solution that can be translated into the Actionscript SDK... But, with the PHP SDK there is a method inside the facebook SDK that is called setFileUploadSupport - try looking in the code for a place to set that parameter to true.