Does Directory API support authentication with OAUth2 Service Accounts flow?
I tested the serviceAccount.php google-php-api-client example using the scopes https://www.googleapis.com/auth/admin.directory.group and https://www.googleapis.com/auth/admin.directory.user and it didn't work.
You need to authorize the service account client ID to access the given API scopes in the Google Apps Control Panel. See the step as described in the Drive API docs, just sub in your Admin SDK scopes.
Note that IMHO, there's very little advantage to using a Service Account with Directory/Reporting APIs as you still need to impersonate a user who has super admin (or proper delegated admin) roles in order to perform and API calls. To me it makes just as much sense to just get a 3-legged OAuth 2.0 refresh token which supports offline from the admin. 3-legged can be done entirely programmatically where-as Service Accounts require the manual step above.
Short answer: Yes. #emilylam question comments hint the error.
Related
I am building an app which authenticates via microsoft and needs various that predominantly uses Delegated permissions. I use the v2 auth endpoints to do incremental authentication, only asking for additional scopes when the user needs them.
This has worked well for the many delegated permissions I have so far. In many cases I need admin approval for these permissions, but I have a flow for that which works well.
One of the scopes I have used as a delegated permission is "User.Read.All", I now need the same scope on the application permission level. But I am struggling to work out if there is a way to do incremental authentication for application permissions. The docs say to use the generic endpoint where you don't specify scopes, but this then asks for all the scopes I have on my application registration rather than just passing in the scopes as a param.
It has nothing do with the endpoint and the scopes you specified. Since you use Delegated permissions in your original job, so I consider you use auth code flow or username/passord flow. If we use auth code flow or username/password flow, we can't get application permission when we do authentication although you have assign the application permissions to your registered app. If you want to get application permission when do authentication, you need to use client credential flow instead.
It is not possible to do this unfortunately the consent flow allows either a dynamic set of delegated scopes to be submitted or /.default which acts like the v1 endpoints and requests all scopes for that client. See these docs
I'm trying to implement security to a backoffice CLI tool (NodeJS) that calls a REST api (Java/JAX-RS) for performing database operations etc.
As we're using Azure AD for all our user accounts I'd like to use it for authenticating our users and also for authorization.
The authorization is needed since not all members of the AD is supposed to use the CLI, and there are two types of users of the CLI with a different set of available commands, meaning that even if you are able to use it, some features might be locked out depending if you are an operator or administrator.
I've managed to create two applications in Azure AD, one for the CLI and one for the API. I can login using our AD credentials, fetch Access tokens for the CLI app id requesting the REST API resouce. On the client side I'm using https://www.npmjs.com/package/simple-oauth2 .
On the Java side the tokens are validated against Microsoft public keys, so everything seems to work out fine.
But, how should I lock down the users to either operator or admin roles? One naive way I can think of is to have the user/role correlation in the REST API and only use the OAuth flow for authenticating the user. But I guess that's what the AD is there for... Could OAuth scopes help me in this case?
Or should the REST API call the AD to query for users group memberships, once it receives the access tokens and knows the end user identity?
Thanks in advance!
Use the Application Roles.
Here you will find good description what application roles are and how to handle them:
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
The recommended resources at the end and also very helpful and will guide you through the process.
Also, when developing CLI it is recommended to use the Device Flow - described here with sample code (.net core) here.
There is a food ordering system. There are around 12 or 13 APIs.
The end-user can search for restaurants, foods, filter things, etc. without logging in to the system. The login is only necessary for placing an order, see past orders etc. So, for like 10 APIs I don't need the user to login.
10 APIs (need to verify the third-party)
The rest (need to verify the third-party as well as the user)
The oAuth 2.0 solutions I have seen so far, they instantly asks for the users to login which is something I don't want.
It'd be really helpful for me if someone takes the time to explain a possible solution and how all those could fit together.
If no Authentication is required, then the information is "Public" and does not need protection from OAuth 2.0.
It would not be unusual for a APIs to be called by a WEB Application where the WEB Application needs to use OAuth 2.0 to access the APIs, but the end-user has no relation to the APIs. So the WEB Application needs an OAuth 2.0 client_id for access to the APIs. The client credentials grant is designed for this use-case: (RFC 6749 Section 1.3.4)
when the authorization scope is limited to the protected resources
under the control of the client ... when the client is acting on its
own behalf
The WEB Application may then at some point use OpenID Connect to Authenticate the end-user for access to some of the "protected resources".
We want to use Google Doc API to generate Document (In our own business account) when our end users do some actions on our site.
The problem is that we've tried to implement the OAuth 2.0 protocol, as suggested in the v3.0 protocol documentation. The apiClient::authentication method do a redirection. This is a major problem because our users doesn't know the access to our own business account.... and we don't want to give them access anyway ;)
(In other word, we're not creating an application that allow our users to edit their own data, but to interact with our data, like a database.)
I've read that the point of OAuth 2.0 was to avoid that we manage the credential of our users. I'm personally O.K. with the concept, but in our case, we don't want to get authenticated in the google account of our users ...
So, what would be the best approach to get a valid authentication without any interaction from the end user ?
What you describe is not how 3-legged OAuth was designed to be used.
3-legged OAuth is all about delegated authentication where a user (who knows his password) can grant limited and revokable resource access to application. That application never sees the user's password. There is a bunch of work involved to safely allow the application to impersonate the user.
What you probably want is to use the (2-legged) OAuth flow, where the consumer_id/consumer_secret credentials are embedded in your application. Here your application is not impersonating your end user and there would be no browser redirection involved.
Here's some further info on using 2-legged OAuth in Google Apps:
http://googleappsdeveloper.blogspot.com/2011/07/using-2-legged-oauth-with-google-tasks.html
And this is a good description of 3- vs 2- legged OAuth:
http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/
You will need to use a SERVICE ACCOUNT. Basically you are hard coding access to this account into your server application. Then you use sharing to give access to the to account for the content you want. For example you can share a Google Doc or an Analytics profile with the SERVICE ACCOUNT.
Here is a complete example implementation of setting up a service account, logging and and then using it.
Updated 2018-12-12: https://gist.github.com/fulldecent/6728257
Why not get one OAuth authorization for your business account and have all users use that account. Since it sounds like you want everyone accessing the data for one account, the details can be hid from the end user.
The access token would be shared by all users and they would all hit the same account back end without any authorization for each user's own account.
The oAuth protocol comes in two flavors, 3-legged and 2-legged protocols. The 3-legged one is about delegating user access rights to an application and is the one that gets the most attention on the web. The 2-legged version is used to authenticate an application against a service provider (Twitter in my case) with no specific user involved.
In my application I need read only access to publicly available information, but at higher rate than the one available to unauthenticated request. There is no need for me to authenticate as a specific Twitter user.
Does Twitter support the 2-legged version of oAuth?
Boaz
PS. The whitelisting alternative is an overkill for me and I rather not wait for the approval process.
You can get an access token for a single user following these instructions: http://dev.twitter.com/pages/oauth_single_token