We are upgrading our OAuth1 Google Apps marketplace app to OAuth2
On upgrade old app is uninstalled, new app is installed but data access is not granted automatically
Old app scopes:
https://apps-apis.google.com/a/feeds/user/#readonly # provisioning API
New app scopes:
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/admin.directory.user.readonly # directory_v1 API
https://www.googleapis.com/auth/appsmarketplace.license
I don't understand were is the problem.
AFAIK In old OAuth1 apps userinfo and LicensingAPI access was enabled automatically. ProvisioningAPI and Directory_v1 scopes match.
What we should change to grant data access automatically on upgrade.
The scope https://www.googleapis.com/auth/appsmarketplace.license counts as a new scope, and prevents the authorization from being transferred during the upgrade. Instead of asking the admin of the domain to grant access to this scope, grant access to this API once as the developer of the application and use that token to access this API for all customers.
Related
I'm trying to authenticate my users (from my RN application) through the LDAP server (I've already found one to try authentication here, and it works!). I can create a custom token using Firebase every time I receive the credentials of the users (username and password) and save it in the Firebase real-time database.
The main problem is that I do not know how to connect my application with the LDAP server, I investigated and found that I have to install something like openLDAP or ldapjs but I do not understand how authentication has to be
My guess is:
User login in my RN application
The RN application sends credentials to Firebase
Firebase creates a custom token (uses the Firebase Functions to generate the custom token)
Firebase returns the custom token to the RN application
The RN application sends the token to the LDAP server (the server has predetermined users and passwords for testing)
The LDAP server validates the token, therefore, authentication
LDAP server returns attributes or "not found" to the RN application
RN App grant / deny access to the app
Any help or advice will be well received, thanks :)
Sorry for my bad english.
You're almost there, but instead of sending the Firebase custom token to the LDAP server, you authenticate the user with the LDAP server before minting the Firebase token. Both of these must be done in a trusted environment, such as a server you control or Cloud Functions, and you'll typically use a Firebase Admin SDK on that environment.
So:
User login in my RN application.
The RN application sends credentials to trusted environment.
Trusted environment verified credentials with the LDAP server.
Trusted environment creates a custom token using the Firebase Admin SDK. If needed this token can contain custom attributes from the LDAP server, in the form of Custom Claims.
Trusted environment returns the custom token to the RN application
RN App grant / deny access to the app
For more on this, see the Firebase documentation on custom auth. From there:
To achieve this, you must create a server endpoint that accepts sign-in credentials—such as a username and password—and, if the credentials are valid, returns a custom JWT. The custom JWT returned from your server can then be used by a client device to authenticate with Firebase (iOS, Android, web).
We have an app in Azure AD that uses the Microsoft Graph API. The app is working successfully using 4 basic permissions: email, profile User.Read User.ReadBasic.All
These permissions let normal users(non-admins) OAuth authenticate into our app.
We are now building a feature for admin users that lets them see their groups. The groups scope requires admin consent as per: http://graph.microsoft.io/en-us/docs/authorization/permission_scopes
The sticky point is that if I add the Group.Read.All permission under delegated permissions in Azure AD, this causes normal users to be able to login with the dreaded error "AADSTS90093: Calling principal cannot consent due to lack of permissions".
I have tried manually crafting OAuth authorize urls that explicitly request the scope, but that did not work either. Here is a sample url I used:
https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&redirect_uri=https%3A%2F%2Fl.xxxxxx.com%3A50000%2Fauth%2Fmicrosoft_graph%2Fcallback&client_id=xxxxxx-xxx-xxx-xxx-xxxx&scope=https%3A%2F%2Fgraph.microsoft.com%2Femail%20https%3A%2F%2Fgraph.microsoft.com%2Fprofile%20https%3A%2F%2Fgraph.microsoft.com%2FUser.Read%20https%3A%2F%2Fgraph.microsoft.com%2FUser.ReadBasic.All%20https%3A%2F%2Fgraph.microsoft.com%2FGroup.Read.All
How can I require basic permissions for all users but have admins request additional permissions later on in the application?
Some resources I've already reviewed to no avail:
http://www.mikepackdev.com/blog_posts/2-Dynamically-Requesting-Facebook-Permissions-with-OmniAuth
https://azure.microsoft.com/en-us/documentation/samples/active-directory-dotnet-webapp-openidconnect-v2/
Switching between web and touch interfaces on Facebook login using Omniauth and Rails 3
https://github.com/zquestz/omniauth-google-oauth2/issues/143
https://azure.microsoft.com/en-us/documentation/articles/active-directory-protocols-oauth-code/
https://github.com/Azure/azure-content/blob/master/articles/active-directory/active-directory-devhowto-multi-tenant-overview.md
The Azure AD V2.0 endpoint already support incremental and dynamic consent. You can register the app to use Azure AD V2.0 authentication endpoint from here.
We can provide two buttons for normal users and admin to login in. Here are the steps using V2.0 endpoint for normal users to login for your reference:
1.sign in and get OAuth Code:
GET: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={clientId}&scope=openid%20https%3A%2F%2Fgraph.microsoft.com%2FMail.ReadWrite%20https%3A%2F%2Fgraph.microsoft.com%2FUser.ReadBasic.All%20https%3A%2F%2Fgraph.microsoft.com%2FUser.Read&response_type=code+id_token&&redirect_uri={redirectUri}&nonce=678910
2.Request for the Access token
POST: https://login.microsoftonline.com/common/oauth2/v2.0/token
client_id={clientId}&scope=openid%20https%3A%2F%2Fgraph.microsoft.com%2FMail.ReadWrite%20https%3A%2F%2Fgraph.microsoft.com%2FUser.ReadBasic.All%20https%3A%2F%2Fgraph.microsoft.com%2FUser.Read
&code={codeFromPreviousRequest}&redirect_uri={RedirectUri}&grant_type=authorization_code&client_secret={client_secret}
And for the admin to login in, we just add the additional scope with above request. Here are some helpful articles about this topic:
What's different about the v2.0 endpoint?
v2.0 Protocols - OpenID Connect
v2.0 Protocols - OAuth 2.0 Authorization Code Flow
Working off pages like this, I have a "service/daemon" test app working with the O365 mail REST API: i give consent to the app, an app-only token is granted via a X.509-signed client assertion, and i can read info from an arbitrary mailbox. It works great.
But our app will be installed for various clients on their private machines -- so it's like a native app, but we need the global permissions that app-only tokens are required for (which is why we aren't a native app).
Since access tokens are granted only based on our app credentials, i think they won't work for us: Customer A could get an access token for Customer B's private data using just the app credentials and the Azure AD tenant ID.
Is there any way to "require client secret for app-only token generation and restrict calls to this tenant ID"? I could then make a secret key for each customer.
Or if a cert could be restricted to a particular tenant ID, we could make a separate cert for each customer.
Having each customer define an app of their own isn't a realistic option, as it's far too complicated for them, requires cert generation, editing the manifest, etc etc.
Maybe there is a back-door way to get app-only style global access with a 'native app' architecture? E.g. if our customer has an admin account, could we authenticate with the 'native app' style oauth grant for that one admin user, and access all users' email via that account's permissions?
For use with the Azure API Management, I am trying to add Applications to an Azure Active Directory (AAD) programmatically, in my case by using the Graph API.
My scenario is the following: In order to secure a Web API I want to manage with Azure API Management, I want to leverage AAD's OAuth functionality to do the heavy lifting regarding authentication and issuing JWT Tokens, and then just use the validate-jwt policy to verify everything is okay in Azure API Management. This has the advantage I can more or less omit authentication in my backend service.
This works fine, as long as I have created an application in the Azure AD for the consuming web application, but this has to be done manually from the Azure Portal; Azure APIm does not do it automatically.
Now for what I am trying to do to get the done automatically: I wanted to delegate the subscription to APIs in APIm to some other web app I am writing, and from there I want to leverage the Graph API to create an Application in the Azure AD and grant permissions to the Application of the API.
The first thing I tried to do was to have a third application (my service application) to have full application permissions to the Windows Azure Active Directory application in the Azure AD; this lets my application access AAD using the Graph REST API. I manage to get an Access Token using the client_credentials grant (from login.microsoft.com), but this Token does not let me do a POST on https://graph.windows.net/(my AAD ID)/applications?api-version=1.5:
{
"odata.error": {
"code": "Authorization_RequestDenied",
"message": {
"lang": "en",
"value": "Insufficient privileges to complete the operation."
}
}
}
I found (https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes) that even if I grant the Directory.ReadWrite.All permission, the application (app-only) will not be able to create or update Applications:
Note: Specifically excludes create or update for entities not listed above.
This includes: Application, Oauth2PermissionGrant, AppRoleAssignment, Device,
ServicePrincipal, TenantDetail, domains, etc.
The next thing I tried was the Resource Owner Password Grant (grant_type=password), passing my own credentials additionally, so that I can impersonate myself in the Graph API. Now, my POST to the applications end point succeeds.
My bottom-of-the-line question is: Can I grant sufficient permissions to my application so that I can add applications programmatically using the client credentials flow, and not any flow which acts on behalf of a user? And if so, how is it done?
Sorry Don. We don't currently have any permission scopes for the client credential flow (app-only) that can be used to create applications or service principals or create any oauth2 permission grants (or any of the other entities that you mentioned above through the Directory.ReadWrite.All permission). We are working on additional app-only permissions that will enable you to light up this scenario, but I don't have an ETA that I can give you.
This operation should be possible if you use the app+user (code flow) and grant the app the Directory.AccessAsUser.All permission - as long as there is a user using your app AND that they are a tenant admin. Not sure if this is an acceptable workaround for you (and I guess is similar to what you are using with the password flow - although I would recommend you use the code flow here).
UPDATE: There are a couple of new app only permissions we added for AAD Graph. Application.ReadWrite.OwnedBy (which allows an app to create/own another app - but only update the apps it created - it won't be able to touch any other apps it doesn't own) AND Application.ReadWrite.All (which allows an app to create/manage ALL apps in a tenant). Seems like the first one would be appropriate. You can see these show in the Azure Portal for the AAD Graph resource.
I have a large customer base and would like to migrate them from using OAuth1 2LO to OAuth2 Domain-Wide Delegation and
1) Would like to know if it's possible.
2) If possible, can it be done without user intervention/impact.
For reference, I am looking at/following the OAuth1 migration doc (https://developers.google.com/accounts/docs/OAuth_ref#migration):
According to the delegation docs, we'd want to create a "service account", but the OAuth1 -> OAuth2 migration guide (https://developers.google.com/accounts/docs/OAuth_ref#migration)
Your application must have an OAuth 2.0 Client ID. You get this Client ID by registering the application as an installed app or a web app in the Google Cloud Console.
1) Does this also work for "service accounts"?
If the migration does work for service accounts, there appear to be manual steps on the part of the admin for setting up delegation (found here: https://developers.google.com/drive/delegation)
The service account that you created now needs to be granted access to the Google Apps domain’s user data that you want to access. The following tasks have to be performed by an administrator of the Google Apps domain:...
2) Does this mean that we will require our customers to complete these steps ?
Any help would be appreciated
There is no token migration involved for the delegation case (so, ignore the migrations docs: https://developers.google.com/accounts/docs/OAuth_ref#migration).
In order to migrate to OAuth2 in this case, you will have to implement Google's 2-legged OAuth2. For information on how to do so, check out Google's 2-legged OAuth2 and Google Drive SDK delegation docs.
Hope that helps!