I am building an app for the Google Marketplace and just made the switch to OAuth 2.0 from 1.0 before final deployment.
Before the switch, I was able to use the provisioning API to fetch users in a domain that has installed the app given, appropriate permissions have been granted.
My experience with the Directory API (the OAuth 2 counterpart) requires that i perform a 2-legged OAuth to get an access token which I then uses to perform the Admin action. This only works if the access token belongs to an Administrator user of the subject domain.
There's a section in the app that pulls all users from the domain and I need this to be accessible to all logged in users including non-administrative users of the domain.
Didn't have such problems when I was using the provisioning API using the Zend library
Not sure. But the following post might be helpful
Until recently this technique was mostly performed using 2-Legged
OAuth 1.0a (2-LO). However, with the deprecation of the OAuth 1.0
protocol and the resulting programmed shutdown of 2-LO, the
recommended authorization mechanism is now to use OAuth 2.0 and
service accounts.
source -
http://googleappsdeveloper.blogspot.com/2012/11/domain-wide-delegation-of-authority-and.html
Related
I use Google OAuth to sign in my Web Application which was created as a project in Google Cloud Platform i.e. Project1.
I have a user with custom role in this project. After I logged in with my Google account, I'm able to get userinfo using Google_Client (PHP library - google/apiclient). However, I'm having a hard time figuring out how to get the custom role for the logged in user. I tried using Google_Service_iam but get Uncaught Google_Service_Exception: 404 Not Found.
Is this a correct way of building a role based control web app utilizing Google IAM?
Although it would be somehow possible by building it yourself, I would not directly use IAM as an authentication provider. Instead, use the Identity Platform or something like Auth0 or Okta. Myself, I prefer Firebase Authentication, which integrates easily with all popular languages and frameworks.
IAM is meant to authorize users within GCP, and not in a custom web-app. In your setup, you would have to add every future user to Gsuite and IAM, which is very costly and not designed for this purpose.
I would recommend taking a look at the Authentication Strategies for application developers.
Since you need to grant to Google Cloud APIs on behalf of an end user, you may use the protocol OAuth 2.0 protocol. The application initiates an OAuth consent flow where you application will receive the user's credentials. With these credentials, it can call Google Cloud APIs on behalf of the user.
Another solutino as Nebulastic also suggested, is the Cloud Identity Platform, where you can configure custom claims to restrict a user's access to a resource depending on their role.
We have an app that uses the OAuth2 Google sign-in system and we want to store data from the users that sign in into our app on our back-end during the initial registration.
This is the way we got it set up:
Users signs in with the app using Google sign-in
We get an ID Token and send this to the server
On the server we verify this token is valid using Google library and save the info we get back from the verification
We also need the user to be able to update/insert data into the back-end when he's authenticated.
After the initial registration, how do we do this?
Do we send the ID Token from client to server each time they call the API on our back-end? In this case how to handle expired tokens?
If you want to make your API a first-class citizen in your system and have it require access tokens that are specifically issued to it instead of accepting Google authentication related tokens that were issued to your client application then you need to have an authorization server that specifically issues tokens for your API.
This authorization server can still delegate user authentication to Google, but then after verifying the user identity it will issue API specific access tokens that better satisfy your requirements, like for example, including specific scopes then used by your API to perform authorization decisions.
For a more complete description of this scenario you can check Auth0 Mobile + API architecture scenario.
In this scenario you have a mobile application ("Client") which talks to an API ("Resource Server"). The application will use OpenID Connect with the Authorization Code Grant using Proof Key for Code Exchange (PKCE) to authenticate users.
The information is Auth0 specific and you can indeed use Auth0 as an authorization server for your own API while still maintaining Google authentication support, however, most of the theory would also apply to any OAuth 2.0 compliant provider.
Disclosure: I'm an Auth0 engineer.
Im trying to use ADFS for SSO on a project. The project is on PHP and Im trying to use OAuth for this.
So what are the steps for setting up ADFS to work with OAuth2? I have no idea about ADFS and cant get any direct guide on OAuth2 settings there.
Thanks a lot.
I see that the question is quite old. But in case if other people will
get here, I have some answer which should be good for March 2019.
Let me start with a general overview.
SSO
SSO could be done with personal Google, Facebook, GitHub, Twitter, Microsoft accounts. After logging in to your account, you can log in to other systems (e.g. WordPress or any other) without password (if other systems integrated with that Identity Provider) and you give the consent (see picture below).
There are services whose main focus is to provide Identity Provider / SSO capabilities (e.g. Okta, Auth0, Google Cloud Identity, Azure Active Directory, AWS IAM).
In the corporate network, the user could be silently signed in based on the AD account without entering credentials via ADFS.
Actually, ADFS supports different authentication protocols like SAML, WS-Fed, and OAuth. But nowadays usually services implement OpenID Connect which works on top of the OAuth 2.0 protocol.
OpenID Connect flows
There is a number of authentication flows that OpenID Connect defines.
Most preferable ones are:
Authorization Code Flow with PKCE (single-page applications, native applications)
If you are using oidc-client-js, you should use response_type=code to use PKCE.
Public native app clients MUST implement the Proof Key for Code Exchange (PKCE RFC7636])
https://www.rfc-editor.org/rfc/rfc8252#section-6
Note: although PKCE so far was recommended as a mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-12#section-3.1.1
Implicit flow considered as Not recommended:
Clients SHOULD NOT use the implicit grant and any other response type causing the authorization server to issue an access token in the authorization response
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09
Client credentials flow. For service-to-service communication.
How to configure ADFS?
You can find quite detailed documentation with illustrations for "Native app scenario" at Microsoft Docs: Native client with ADFS.
If you are not using ADFS, you can play with the PKCE flow setup in the playground.
JavaScript frontend
Never store client secrets in public applications like JS frontend or mobile apps. It's not applicable to PKCE flow but just in case.
If you have a modern SPA application (e.g. Angular or React), it means that frontend should have only client_id to enable end-user to obtain the JWT access_token in a browser via ADFS. You don't need any client_secret.
oidc-client-js could help you with that. Make sure that code_verifier is being sent along with a token request (it means that you are using more secured PKCE flow).
PHP backend
And on PHP side you'll need to validate the access token. You can implement the workflow on your own according to that article. But it's better to use OpenID certified library which you can find on this page (not only for PHP):
https://openid.net/developers/certified/
So, for PHP there is only one: phpOIDC.
Authentication
OAuth 2.0 can help you only with authentication (to identify the user's identity).
Most probably you would like to have different permissions for different users. And OpenID Connect implementation in ADFS provides you the ability to map AD groups to token claims. Therefore, you can decode JWT access token on the backend and implement claims-based authorization.
To use JWT claims be sure to properly validate the authenticity of the token and issuer:
Validate JWT signature using public key
Check issuer for the proper issuer (Identity Provider)
Check aud (audience) for the proper client ID
Check exp (expiration timestamp)
Check claims
I am working on a PHP Application which uses github oauth. It will be available for everyone to download and use. Users will use it on their own web hosting domains.
The problem is that I cannot set a fixed redirect uri for all of them.
How should I set things up so that the users are able to use my application wherever they install. The OAuth authentication response should always redirect to the origin of the request.
Github OAuth Documentation
Register a new OAuth application at Github
For my specific case, if that matters, only a single user will authorise via Github per installation.
I have recently implemented the SSO functionality for a Google Apps Marketplace app we are developing. In simple words: it provides a way to retrieve the Google Apps' user's email and log him in in your website, without the need of authorization on his end. You just need the consumer key and consumer secret, provided by Google to the app during installation on your domain (the installing user also authorizes (a one time action) any other permissions you request in the Manifest file).
Now I have somehow managed to get the SSO user login working using JanRain's OpenID PHP library and adding Google Apps as provider using the PHP Extensions for Google Apps OpenID Discovery.
However, after logging in, I need to implement a functionality that will retrieve all users in a given Google Apps domain. I've already did that using oAuth2 authentication and the following Directory API. However, this requires the existense of a consumer key, consumer secret and a redirect URL (that must be registered in the Google API console).
Is there a way to remove this convenience and instead allow our users to directly be able to get their Google Apps domain's users, using the existing SSO authentication we made in the background while logging him in? Otherwise, it will be too much hassle for the user to register the app at the Google API console, enter the correct redirect URL and set it up in our website and then he will be able to get his domain's users.
Regular users cannot use the Directory API, you'll need to authenticate as an admin user to make Directory API calls.
Depending on your needs though for accessing all users, you may be able to get by with requesting access to the user's Contacts scope and grabbing a copy of the full Global Address List which contains information on all non-hidden domain users as well as non-hidden groups and shared contacts.