When reading the doc of google oauth API, I found that it does not offer refresh token to Javascript (JS) web app, as mentioned in below link. It says "Refresh tokens are not typically used in client-side (JavaScript) web applications."
https://developers.google.com/identity/protocols/oauth2/web-server
However in the following page it offers the refresh token (as well as client secret) to native app. Seems strange that both JS web app and native app are not confidential. Shoudn't it also not to offer refresh token and client secret to native app?
https://developers.google.com/identity/protocols/oauth2/native-app
Thanks
A refresh token in a client sided application where anyone could view source and see the refresh token and client id and client secret. This would mean that anyone could then create a new access token to access the data.
If I understand what you mean by native apps they are run on a users machine and there by the only one in theory who would be accessing that machine would be the user who is accessing their own data. Native apps can also better protect the various secrets from both the user and other apps. So while it is still an exposure risk - the risk is significantly lower.
Use a server side web language if you want a refresh token.
Related
I am using electron to build a little desktop app to interact with my laravel backend. Im using laravel sanctum here so I can easily get a personal access token via https and then make authorized api requests with it. The token will be stored using node-keytar (main process). I am also using vue.js on the frontend of the electron app.
Now my question is: Do I need to make all authorized api requests in the main process and send the received response via ipc to the renderer process? Or is it safe to make authorized requests (with the personal access token as Bearer token) in the renderer process? Because on the one hand I ve read that as much as possible should be done in the renderer process to ensure performance. But on the other hand I don't know if the token could be intercepted somehow and I can't find much information on this.
Can someone help Thanks in advance!
It is pretty standard for a native client to send tokens directly from the UI to APIs - that is how non Javascript desktop apps would work - eg if coded in Java or C#.
Of course, for an Electron app node integration should be disabled in the renderer process, so the privileged code to use keytar has to run in the main process.
SOMETHING TO COMPARE AGAINST
There is a sample of mine here that uses OAuth for desktop apps with Electron, and keytar for token storage. I call APIs directly when getting data for views, and need to call from the renderer to the main process to deal with token storage.
We have an auth infrastructure based on OAuth2 that is integrated into a variety of web apps within our organization. We also have a pure native application with no middle-ware of its own, and we want to integrate authentication into this native application. This application already has its own internal login mechanism with a native login screen, and we don't want to have it start launching external components like web browsers in order to display login windows. We are both the app provider and the auth provider, so the concern of the app having visibility into the user's credentials is less of an issue -- we trust ourselves to not intentionally do anything untoward with the user's credentials, and it's the same people writing a login form in the app as writing it on a web site. :-)
We are trying to figure out how best to support having the application continue to collect credentials the way it does now, but use them to obtain an auth token within our auth framework. With the APIs in place right now, the only way I can see for it to be done is to bake a Client Secret into the native app so that it can use a Resource Owner Password Credentials Grant request, since the code that would normally be making this call doesn't have a server side to live in. This feels really wrong, somehow. :-P
As far as I can see it, many of the structures of OAuth don't really apply to this app because it's not living in the context of a web browser, it doesn't have any concept of a "domain" nor any sort of "cross-domain" restrictions. It has been suggested that perhaps we create middleware for this app just for the purpose of exchanging authentication codes for tokens, but the rationale for that seems to be that this middleware theoretically ought to be able to somehow vet requests to determine whether they are legitimately from the application, and I don't see any way to do that that couldn't be faked by anyone with access to the client application code. Basically, the only purpose such middleware would serve would be to make the Client Secret irrelevant with respect to getting auth codes for credentials.
One thought that came to us was, how does something like Windows do it? Windows very obviously uses a native login form, but then some flow exists whereby the credentials that are entered are used for authentication and presumably, deep in the internals of the OS, for obtaining an auth token. Does anybody know if this architecture is documented anywhere? Does Microsoft's architectural choices here have any relation to OAuth2? What is the "best practice" for an application if you take it as a given that it doesn't have middleware and has its own native login form?
FWIW you don't need a client secret to use ROPC Grant to obtain or refresh tokens if the client is configured as a public client, i.e. a client that isn't capable of storing a secret.
RFC8252 OAuth 2.0 for Native Apps encourages using a native user agent for your scenario, using authorization code flows with PKCE. Authorization services like Okta and Auth0 have jumped onboard too, although they still recommend ROPC if the client is "absolutely trusted".
RFC6819 OAuth 2.0 Security discourages ROPC, but also says "Limit use of resource owner password credential grants to scenarios where the client application and the authorizing service are from the same organization", which are first-party apps.
So while the security verdict seems to be that authorization code+PKCE is the best practice, the UX hurdle of showing a user a browser window to log into a native app seem to be keeping ROPC alive. It's difficult to tell if that UX is jarring because people aren't used to it or because people can't get used to it.
I'm creating a react native app and adding instagram authentication to it. I want users to be able to "add" their instagram accounts to their main user account, so I have a "connect your instagram" button.
I have this working on my web app fine.. The flow is as follows:
User clicks 'connect instagram' button and a new window opens and is directed to https://instagram.com/oauth/authorize/?client_id=xxxx blah blah
User authenticates and instagram redirects to my REDIRECT_URI with a CODE parameter
My API server takes the CODE parameter and sends a post request to instagram with all the credentials.
Instagram verifies this information and gives me the users ACCESS_TOKEN
Can someone tell me how this is supposed to work in an app?
What's my REDIRECT_URI supposed to be? The server api?
Is it the same flow as my web app? If so, how do I get the users back to my app after the window is closed. How does my app know that the user now has an access token?
With a native application the flow is similar to what you described for the web application.
The Auth0 Mobile + API architecture scenario describes what should happen when you need to authenticate a user for a mobile application and then later access an API on behalf of that user.
Summary
you will continue to use the authorization code grant;
if the authorization server in question supports it you should use the PKCE (Proof Key for Code Exchange by OAuth Public Clients) for added security;
you will need to select how you will receive the code in the native application; you can use a custom scheme com.myinstaapp:, a local web server with the http: scheme or a few other options; (see this answer on OAuth redirect URI for native application for other alternatives)
you exchange the code obtained by the native application with an access token in a similar way to what you would do for a web application; (except for the use of client secrets which are in general not useful for native applications as they would be easily leaked)
Additional Information
The flow described in the Auth0 scenario assumes that authentication will happen through an OpenID Connect compliant flow and in addition you'll get the access token as specified by OAuth2. I'm not overly familiar with Instagram so if they only support OAuth2 that part is of course not applicable.
I have followed the great example on integrating ADAL and Xamarin Forms by Vittorio. I am still struggling though on how to best implement authentication in mobile applications based on Xamarin Forms.
What is the best way to authenticate a user in a mobile application base on Xamarin (forma) knowing that the user is registered in an Active Directory on premise which is synced to an Azure Active Directory? Currently I am using ADAL for that but would it perhaps be better to use Azure Mobile Services? I need a token so that I can authenticate a user in a webapi running in Azure Websites.
When I follow the example of Vittorio, I run into a problem that I don't get a refresh token from the AAD authentication call. I should not that my AAD redirects the real authentication call to an on premise ADFS server. I am not sure if that could be the problem?
for #1 you can use the ADAL sample exactly as is - the only difference is that you need to configure your app to request access to your web API and pass the API resource is when you acquire a token. See setup instructions in https://github.com/AzureADSamples/NativeClient-DotNet.
For the refresh token: ADAL used it automatically from its cache, but people often did not know/understand that and used the returned refresh token manually, doing a lot of extra work... So we are no longer returning the token in the result, but we do use it automatically whenever you call acquiretoken and the token needs renewing.
Facebook's guide on authenticating with the javascript SDK says:
"The Facebook SDK for JavaScript automatically handles access token storage and tracking of login status, so apps using it do not need to create their own mechanisms for doing so, and can proceed to making API calls."
Most of my code will be server-side PHP, but I plan on using this Javascript SDK for authentication. Ideally, I'd like my users to log in as little as possible. From what I understand, that means that once I get a token I should convert it to a long-lived token and store that token in my database for calls over the next 59 days. At that point, I should renew the token before it expires and repeat until the user de-authorizes my application.
I don't understand how I can take advantage of the fact that Facebook is keeping track of my tokens for me. Won't I need the token to make calls using the PHP SDK? If not- what's the difference between PHP calls with PHP authentication and PHP calls with JS authentication? If so- how do I get the token when Facebook says they're keeping track of things for me?