I am trying to write an application that:
In a browser, authenticates a user with a Google account.
Calls a backend service.
Backend access user's drive (and some other things) and then returns JSON.
Frontend: copied some example from the web, can authenticate without issues.
Backend: Node.js/Passport.js. Copied the code from an example, can authenticate.
But how do I authenticate a user in the browser and then do an API call so the API may access the Google Drive? What is the expected flow?
A. Web app authenticates the users then passes id_token to the server?
Can't find how to implement this on a server...
or:
B. Server sends app to, say, /auth/google/ on the same server, then app gets a token from server?
Think of OAuth2 as a permission delegation protocol - user (Resource owner) authenticates and gives a consent to passing an access token (or some other tokens) to the OAuth2 client that initiated the process. When the client receives the access token, it can act on behalf of he user and access resources on a resource server (Google Drive).
So if your backend wants to access Google Drive, the cleanest way would be to make your backend an OAuth2 client, that redirects a user to Google auth server and then receives an auth code. The client must ask for scopes that will allow it to access Google Drive. The auth code can be exchanged for an access token. To access Google Drive, the backend needs to send a valid access token in the Authorization HTTP header of the request.
If you need the tokens on your frontend as well, you can use it as an OAuth2 client and pass them to the backend in an HTTP header.
Related
I used Serverless to create API gateway endpoints + lambda functions. I want to secure API gateway endpoints using the access token oAuth. I am trying to provide credentials (sign up and sign in) in my iOS native app. Here are the facts I learned.
I want to secure my API gateway using OAuth and access token.
Because I have already created API gateway endpoints and lambda functions, Signup and Sign in using Amplify is not the best idea. I can't use Amplify's access token in the API gateway because in the Cognito user pool (under App Client Settings) I have selected Authorization Code grant (instead of implicit which is not that secure and client credentials are for the machine to machine) type OAuth flow.
I have in app Sign up and Sign in UI and don't want to use Hosted UI.
I want to authenticate and authorise users of my app.
My question is:- Can I use the Authorization code grant type without using Hosted UI or web browser? i.e. make a rest call with username and password and get the Authorization code. Once I get the Authorization code then make a call to the token endpoint to get the access token. Once I get the access token then call API gate with that access token. All of the above natively without using a browser or hosted UI.
Thank you very much in advance.
I have a SPA and a backend API service. The google user signs in to the SPA at which point I obtain their access token & id token.
The backend service uses google identity to authenticate users of it using the id token. However one of the the backend services features needs to request data from the google analytics API which requires the users access token.
In this senario do I send both the id token and access token to my back end service?
Yes, in this scenario you could send the access token to your backend service so that it can contact Google's API. In most cases, access tokens are used as bearer tokens, which means that any client in possession of that token can use it to call the API. That's why you can pass a token issued to the SPA to a backend service and still be able to call Google's API.
At the same time, you should think of security implications. You should not send the access token to any services that you're not in control of. Meaning, you should not send the access token to service XYZ because that service needs it to call Google's API with a user's token if service XYZ is not under your control.
I am reading and reading, not sure why it's so hard to properly understand OAuth2 flows, which I thought I understand, until I wanted my own server.
So I have Frontend (web + mobile app aka resource owner), my own API server ( resource server )
and I want to create my own OAuth2 server.
So assuming, that on user registration, I am registering them on my OAuth2 server, saving username and hashed password ( I also want to save organization/project name, so I can user oauth2 server for multiple projects without worry of username duplicates)
Then Frontend obtains access+refresh tokens from OAuth2 server directly with password_grant. Or should I do it through my API and use CLIENT_ID/CLIENT_SERCRET with it (is that even an option)?
With access token, Frontend then now can communicate do my API(resource server)
API (resource server) then communicates with OAuth2 to validate access token - here I am not sure what's the common name of that action authorize or authenticate ?
Once access token is expired, Frontend (resource owner) can communicate directly to OAuth2 to obtain new access and refresh token. Or again - it should go through API and do it with CLIENT_ID/SECRET ?
Currently I did above implementation, but inside my API, but idea of OAuth2 is that it is separated server. Not sure how it will benefit me other than I will be able to use it for other project, but I guess with OAuth2 I can then expose API to public.
Question is, is above correct ? can someone help me wrap it with correct OAuth2 terminology ?
The frontend apps are not resource owners, but clients. Resource owners are users of these apps. These apps are so called public clients - they don't have a secure storage for their client secret, so they must not have a client secret. Instead, they should use PKCE (kind of one-time password) with the the auth code flow.
This way, they receive a refresh token they can use to get valid access tokens. The frontend apps use access tokens to authorize their requests to your backend. Your backend should validate them.
For more info, please see the current best practices - OAuth 2.0 for Browser-Based Apps and OAuth 2.0 for Native Apps.
I've created a FeathersJS backend app and a React frontend app. I'm using OAuth2 strategy to authenticate users to my own WordPress site. Everything is working fine. But now I'd like the users to be able to access my FeathersJS backend REST API, but as they authenticate through the WordPress OAuth2 server, thus following all the OAuth2 authentication process through my React frontend app, which would be the correct FeathersJS way to allow the users authenticate to my backend so that they can do REST API calls?
But now I'd like the users to be able to access my FeathersJS backend REST API
To let people access your backend REST API (which I assume is only possible after they authenticate), you need to check whether the access token they have is, in fact, valid with the third party auth provider.
You can directly let them use the back end API. In case the API doesn't find a valid access token with the incoming request, it will redirect it to the login page. After which, now the backend can validate itself with third-party OAuth provider and return the result.
following all the OAuth2 authentication process through my React frontend app
It is recommended to not do all the OAuth check from front-end since this exposes the access-token on the user agent, which might be a serious issue. See this:
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2#grant-type-implicit
I am developing an application using ASP.NET MVC 5.2.2, Web API 2.2 and Katana/OWIN 3.0. The application uses ASP.NET Identity 2.1 for local accounts and database.
I am using OAuth Authorization Server to generate access and refresh token. I have Android and IOS apps which uses my local oauth authorization server. Android and IOS apps uses SDK to login with Facebook, Google, etc. After that the apps will send the (Facebook/Google/etc) access token to the server. The server will validate access token with Facebook/Google/etc.
If it is valid then,
1) Should I generate new local access token(in Auth header) to apps
for all future request?
2) Should the app send me Facebook/Gmail/etc
access token(in Auth header) every time and the server validate the
access token with Facebook/Gmail/etc each time?
3) If local access
token expire, then the server is using refresh token to generate new
access token. Should the server update the access token as well as
refresh token during this time or updating access token is enough?
after you validate your social provider external access token, you need to exchange this external access token with a local access token issued by your authorization server (Local authority). All the details for this implementation can be found here: http://bitoftech.net/2014/08/11/asp-net-web-api-2-external-logins-social-logins-facebook-google-angularjs-app/
Let me know if this helps.
Here is the exact steps I have followed to change the external access token with access token issues by Local Authority. The front end is an AngularJS application. You can check the demo application here and see how I'm accessing the web api using Facebook access token http://ngauthenticationweb.azurewebsites.net/
1- AngularJS application sends HTTP GET request to anonymous end point (/ExternalLogin) defined in our back-end API by specifying client_id, redirect_uri, response_type.
2- Once the end point receives the GET request, it will check if the user is authenticated, and let we assume he is not authenticated, so it will notify the middleware responsible for the requested external provider to take the responsibility for this call, in our case it is Google.
3- The consent screen for Google will be shown, and the user will provide his Google credentials to authenticate.
4- Google will callback our back-end API and Google will set an external cookie containing the outcome of the authentication from Google (contains all the claims from the external provider for the user).
5- Google middleware will be listing for an event named “Authenticated” where we’ll have the chance to read all external claims set by Google. In our case we’ll be interested in reading the claim named “AccessToken” which represents a Google Access Token, where the issuer for this claim is not LOCAL AUTHORITY, so we can’t use this access token directly to authorize calls to our secure back-end API endpoints.
6- Then we’ll set the external provider external access token as custom claim named “ExternalAccessToken” and Google middleware will redirect back the end point (/ExternalLogin).
7- Now the user is authenticated using the external cookie so we need to check that the client_id and redirect_uri set in the initial request are valid and this client is configured to redirect for the specified URI.
8- Now the code checks if the external user_id along with the provider is already registered as local database account (with no password), in both cases the code will issue 302 redirect to the specified URI in the redirect_uri parameter, this URI will contain the following (“External Access Token”, “Has Local Account”, “Provider”, “External User Name”) as URL hash fragment not a query string.
9- Once the AngularJS application receives the response, it will decide based on it if the user has local database account or not, based on this it will issue a request to one of the end points (/RegisterExternal or /ObtainLocalAccessToken). Both end points accept the external access token which will be used for verification and then using it to obtain local access token issued by LOCAL AUTHORITY. This local access token could be used to access our back-end API secured end points.