I'd like to implement Google OAuth. I'm a bit confused whether to have it implemented in the client (mobile app) side or the server side!!
Implementing it in the client side would mean shipping the key and secret in the app (which I want to avoid). However, if I do it in the server side, how do I send back the correct response to the client after a successful callback?
Also, what are the benefits of each of the two implementations?
If you're talking about implementing the Google+ OAuth 2 authentication from a native mobile application (not a web view), then, what you need is to create an installed application client and a web application client in the google console. The first one is for your mobile application, and the second one for your server.
Here is the workflow I used for my application :
the mobile application gets the authorization code from google with the g+ sdk, using a scope containing the web application client id. That way, the server has the authorization to connect with google+.
Your scope could look like something like this:
String LOGIN_SCOPES =
"https://www.googleapis.com/auth/plus.login " +
"https://www.googleapis.com/auth/userinfo.email";
String SCOPES = "oauth2:server:client_id:" + GOOGLE_SERVER_CLIENT_ID + ":api_scope:" + LOGIN_SCOPES;
the mobile application calls a server route with the authorization code and the proper redirect uri (the one associated with the installed app in google dev console which usually looks like this 'urn:ietf:wg:oauth:2.0:oob').
the server gets the access token from google with the authorization code, secret id, application id, and the installed application redirect uri (if you use the web application one, it will fail with a redirect_uri_mismatch error).
the server does whatever it wants with the access token, creates a valid session and gives it to the application as a response to its request.
That way, you don't need to store anything on the client side. You still need to send the authorization code from the client to your server (preferably https), but this code can only be used one time and is immediately consumed by the server.
I hope it helps.
Related
I'm tasked with making a server using Node.js which will read emails from a Google account and parse the content from those emails into data we can store in a database. I'm using Google's googleapis package (v103.0.0) in NPM to authenticate/authorize with whichever account we'd like to use.
The issue comes when we try to switch accounts and have the user re-auth. During development on a local machine, the Auth process works as expected:
The client requests an Auth URL.
The server generates a new Auth URL and sends it back to the client.
The client redirects to that URL and the Google Consent Screen is shown.
The client is asked to choose between logged-in Google accounts.
The client authorizes the application and is redirected back to the server with a code.
The server uses the code to generate/save a token, which allows it to use the Gmail API.
However, after deploying to Heroku, the Google Consent Screen no longer allows the user to select an account. Instead, at step 3, it shows this message. In just about every other question related to this error, there's always additional information below the error code/message, but nothing's there for me. I made sure: (1) the domain I'm using in Heroku is verified on the Google Cloud Console, and (2) the redirect_uri within the Node.js application is passing the correct domain to the Auth URL, even while in production.
I can't provide the URL for privacy reasons, but let me know if there's any source code or Cloud Console info I should include.
It didn't take long after posting this question, but I realized I was using an incorrect OAuth 2.0 Client ID type. I was attempting to use "Desktop" when I should've been using "Web application" instead. Take a look at this image to see the difference.
When you select "Web application", you're given some new options: Authorized JavaScript origins, and Authorized redirect URIs. This is where you need to fill out the allowed URIs. Here's a sample of what that should look like.
I need to do a communication between two applications, and I want to ensure the client application identity.
I wanna know if is there some pattern to make something like this:
The client application has a key and secret
The client send some info to the main application with identity data
The main application verify the client and returns the requested data
You may want to investigate client and server TLS certificates. They will allow for a mutual authentication between the server and the client.
I think You are talking about server-client communication. In this case, you have to search RESTful API. With REST, you implement endpoint which returns your data as a JSON. So you can use the data in Desktop app,Mobile app or Web app and with this way you can resolve the security risk. Because in mobile app
or desktop app, conneting to db is risky. You cant put your db options in your app. Implement a REST which returns JSON and send a http request in client.
If response is OK. Parse the JSON and use in the client
Here is the simple example in php
My question is [Similar to this one1, but with third party providers instead of active directory.
I have an end-user UWP app, and I want to consume my Azure API App. I am NOT Azure mobile app and it's client side SDK.
Most of documentation is of sort "copy paste this magic code" and never explains how authentication actually happens.
I was inspecting mobile app SDK because Microsoft's documentation says that it's auth. process is the same.
From what I see, the mobile App SDK opens a web-view very similar to that produced by a WebAuthenticationBroker. Then every request to the server is accompanied by a header X-ZUMO-AUTH and a token. It appears that this token is issued by the azure app service, not the original provider. It is much longer than the tokens issued by Twitter or Google.
At the same time when I point web-browser at the end-point and go through the log-in process, I see that the browser is using a Cookie: ARRAffinity=c4b66198677464de573103f7aa267c33ea38617020514011cea4506e0a55d9d0; AppServiceAuthSession=EIVymV
Questions:
The problem is Mobile app documentation is it just provides
instructions on how to use the SDK. I am unclear on how I would
obtain the token issued by the app service.
Everyone knows how to obtain access tokens for Google
and Twitter. Can they be used to access Azure API apps?
You are correct that API apps use the same built-in authentication as mobile apps. The basic flow looks like this:
Login to the app using provider credentials. This can be done using either a client-directed flow using your provider's SDK or can be done using a server-directed flow involving browser popups (i.e. the web view you mentioned). In the latter case, there is an endpoint at /.auth/login/ which is provided by App Service and manages the login flow for your app.
App Service will respond to your client app with a session token (a JWT).
You call into your APIs using the session token from #2. It is passed via the x-zumo-auth HTTP request header (it's named this way for legacy reasons).
The AppServiceAuthSession cookie you are seeing is the session cookie for when you use a browser to do authentication. ARRAffinity is an internal routing cookie used by App Service and is not related to auth.
If you're looking for more internal technical details on how the built-in App Service Authentication / Authorization works, check out my blog, starting with this post: http://cgillum.tech/2016/02/01/architecture-of-azure-app-service-authentication-authorization/
Consider the following (common) scenario. I will first try to specify how I understand a (nice) Web API should look like, using OAuth. Please do correct me if I got any of the flows wrong.
My API: the center of attention, all clients use this.
My Web App: Uses the API just like any other client would.
My Mobile App: Also uses the API, the same exact way as the web app. Users should be able to authenticate without opening a browser.
3rd party Web App: Also uses the API - however, the user/resource owner must grant permission for the app to do something. They do this by redirecting to my site (or opening a popup to it), logging the user in if necessary, and prompting the user for access.
3rd party Mobile App: Same requirements as the 3rd party web app.
The Question(s)
Should the API handle authentication and authorization?
How does the API know who (the resource owner that is using the client application), is using the API?
When a user is using my official clients, they should obviously not have to grant any permissions - my clients should have all permissions. How would I distinguish between my official clients, and 3rd party clients when calling the API?
Here is what I understand, and would do so far. This is where I really need help - getting this done right.
Official Web app
- Client attempts to `GET /api/tasks/".
- API says "who are you? (HTTP 401)
- Official web app redirects to login form.
> Bob enters his credentials.
- .. now what? Get an authentication token? Cookie?
Since the web app is just a consumer of my API, how would I manage the logged-in state? Should the web app do that?
Should the web app have direct access to the users database instead of verifying credentials against the API?
I am using .NET (C#) primarily, but I'd love an approach that is applicable to, say, Node JS based API's as well.
How would you go about this? Especially the client flows are a problem for me. The reason I ask, is that I have read that you should not roll your own security solution unless absolutely necessary, so if there are any standard-ish guidelines for this, do let me know. :)
Take a look at the new web API 2 oAuth stuff.
Basically fire up a new web API project and ensure you select to change the authentication.
Then, it's a simple case of calling the register controller. This then creates a token for you which can then be sent in the header of each request for that user.
Check out the API calls using fiddler and create some mock up accounts.
It's been awhile, but I thought I would document what I ended up doing.
I use DotNetOpenAuth. I have a database with clients, and they have a Trusted field - if this is set, it lets the client use the password grant, which automatically grants all scopes that have been predefined for that client.
The 1st-party web app uses plain cookie auth - exposing the client credentials in JS would be too risky.
Is browser redirection necessary to get autorization and access token ? Is there a way how to get autorization programatically ? I am a bit suprised i found this in the OAuth2 google documentation :
https://developers.google.com/accounts/docs/OAuth2#scenarios > Chapter Installed Application
sequence begins by redirecting a browser (either a browser embedded in the application or the system browser) to a Google URL with a set of query parameters that indicate the type of Google API access the application requires...
We run small java utility app which contains username and password in config file to our google account. i would expect there will be way to get autorization and access token without any browser interaction (it`s a bit hard to do when we run it as a cron job on virtual server)...
It's about trusted path between credentials holder (user), and authentication entity (it can by google app's server, or openID or facebook...). Someone who uses OAuth, provides his credentials to server he trusts, and in turn this server not revealing any secret data about him, provides identity assurance for your app.
So you have to provide trusted path to Oauth porvider. This can be done by opening a simple http server within your app, and opening user browser pointing to it, and then authentication would be done using, browser, and after auth is finished your server would recvive OAuth response and your app could authenticate user.
That's the idea, I would not input my "global" credentials to some app, and trust it that it will not, copy and use them later on. You've registered within specific OAuth provider and only he should know, and recive your credentials.