I need to get access at the sheets and I am following this guide to start to do that https://developers.google.com/sheets/api/quickstart/nodejs
But the button that enables google APIs doesn't work, all names I put on the project return an error.
I went on the API console and created a new project but I do not know how to get credentials files (if they are needed) and then I must create an URL for the OAuth page?
How to get OAuth crendetials manually
There different types of crendetials and the procedure to obtain them is slightly different depending on your situation.See here for the different scenarios.
In most cases (an exception is when using a service account), the first step is to set up an OAuth consent screen.
The consent screen is the screen your users see when they are prompted to agree to terms that are presented to them by your application
To set up a OAuth consent screen, go after chosing a project from the GCP console on APIs & services -> OAuth consent screen
You need to chose either your application is supposed to accessible only by domain internal users or also external (in the latter case you might need to submit your application for verification by Google, pontentially involving costs - depending on the scopes you use).
You need to provide an application name that your users will see (the logo is optional)
You need to specify which scopes your app will use
You can specify other properties, e.g. the Authorized domains (this is usually your website from which the users will be redirected to the consent screen when performaing some kind of action)
If you are not sure about the optional properties, leave them out for the start
Once you set up the authentication screen, the second step is to go on APIs & services -> Credentials
Read the Authentication overview to decide which credentials you need
For most applications you will want an OAuth client ID
The diffrent Application types are described here, to start with create a Web Application
Authorized JavaScript origins and Authorized redirect URIs is basically your Webpage from which the users will be redirected to authenticate and to which they should be redirected after authentication.
For local testing you do not need to specify those URLs
Once you create the OAuth2 client successfully, you will obtain the Client ID and Client Secret - your crendetials to incorporate into your code when using Google APIs.
If you click on the download button on the right side of your newly created credentials - it will generate a json file on your local machine from which the credentials will be read automatically if you follow the quickstart.
Alternatively you can paste the credentials directly into your code - see here for sample for different situations
I have an OpenID Connect provider built with IdentityServer4 and ASP.NET Identity, running on let's say: login.example.com.
I have a SPA application running on let's say spa.example.com, that already uses my OpenID Connect provider to authenticate users through login.example.com and authorize them to access the SPA.
I have a mobile app (native on both platforms) that is using a custom authentication system at the moment.
I thought it would be nice to get rid of the custom auth system, and instead allow my users to log-in with the same account they use on the SPA, by using my OpenID provider.
So I started by looking on the OpenID connect website and also re-reading the RFC6749, after a few google searches I realized that was a common problem and I found RFC8252 (OAuth2 for Native clients), also Client Dynamic Registration (RFC7591) and PKCE (RFC7636).
I scratched my head about the fact that it was no longer possible to store any kind of "secret" on the client/third-party (the native apps) as it could become compromised.
I disscussed the topic with some co-workers and we came out with the following set-up:
Associate a domain let's say app.example.com to my mobile app by using Apple Universal Links and Android App Links.
Use an AuthenticationCode flow for both clients and enforce them to use PKCE.
Use a redirect_uri on the app associated domain say: https://app.example.com/openid
Make the user always consent to log-in into the application after log-in, because neither iOS or Android would bring back the application by doing an automatic redirect, it has to be the user who manually clicks the universal/app link every time.
I used AppAuth library on both apps and everything is working just fine right now on test, but I'm wondering:
Do you think this is a secure way to prevent that anyone with the right skills could impersonate my apps or by any other means get unauthorized access to my APIs? What is the current best practice on achieving this?
Is there any way to avoid having the user to always "consent" (having them to actually tap the universal/app link).
I also noted that Facebook uses their application as a kind of authorization server itself, so when I tap "sing-in with facebook" on an application I get to a facebook page that asks me if I would like to" launch the application to perform log-in". I would like to know how can I achieve something like this, to allow my users login to the SPA on a phone by using my application if installed, as facebook does with theirs.
I thought it would be nice to get rid of the custom auth system, and instead allow my users to log-in with the same account they use on the SPA, by using my OpenID provider.
This is what OAuth 2.0 and OpenID Connect provides you. The ability to use single user identity among different services. So this is the correct approach .!
it was no longer possible to store any kind of "secret" on the client/third-party (the native apps) as it could become compromised
Correct. From OAuth 2.0 specification perspective, these are called public clients. They are not recommended to have client secrets associated to them. Instead, authorization code, application ID and Redirect URL is used to validate token request in identity provider. This makes authorization code a valuable secret.!
Associate a domain let's say app.example.com to my mobile app by using Apple Universal Links and Android App Links.
Not a mobile expert. But yes, custom URL domains are the way to handle redirect for OAuth and OpenID Connect.
Also usage of PKCE is the correct approach. Hence redirect occur in the browser (user agent) there can be malicious parties which can obtain the authorization code. PKCE avoid this by introducing a secret that will not get exposed to user agent (browser). Secret is only used in token request (direct HTTP communication) thus is secure.
Q1
Using authorization code flow with PKCE is a standard best practice recommended by OAuth specifications. This is valid for OpenID Connect as well (hence it's built on OAuth 2.0)
One thing to note is that, if you believe PKCE secret can be exploited, then it literally means device is compromised. Think about extracting secret from OS memory. that means system is compromised (virus/ keylogger or what ever we call them). In such case end user and your application has more things to be worried about.
Also, I believe this is for a business application. If that's the case your clients will definitely have security best practice guide for their devices. For example installation of virus guards and restrictions of application installation. To prevent attacks mentioned above, we will have to rely on such security establishments. OAuth 2.0 alone is not secure .! Thats's why there are best practice guides(RFC68129) and policies.
Q2
Not clear on this. Consent page is presented from Identity Provider. So it will be a configuration of that system.
Q3
Well, Identity Provider can maintain a SSO session in the browser. Login page is present on that browser. So most of the time, if app uses the same browser, users should be able to use SPA without a login.
The threat here comes from someone actually installing a malicious app on their device that could indeed impersonate your app. PKCE prevents another app from intercepting legitimate sign in requests initiated from your app so the standard approach is about as safe as you can make it. Forcing the user to sign in/consent every time should help a bit to make them take note of what is going on.
From a UX PoV I think it makes a lot of sense to minimize the occasions when the browser-based sign in flow is used. I'd leverage the security features of the platform (e.g. secure enclave on iOS) and keep a refresh token in there once the user has signed in interactively and then they can sign in using their PIN, finger print or face etc.
I ran Google Cloud Security Scanner against my Google App Engine app. I asked it to authenticate against a "Non-Google Account" -- in other words, user-name/password fields in my webapp. However, I get back the message "Could not sign in using the provided username and password" each time.
(I tried it several times, specifying different user-agents and credentials and against two variants of my login page; and of course confirming that the credentials work when typed in manually. I have the necessary Editor-level permissions on the Google Cloud project.)
What do I need to do to get the Scanner to authenticate?
Here's what the docs say about Non-Google account authentication:
Note that support for login forms is still in development, and may not
work out-of-the-box with your system. If you have confirmed your test
account is able to login manually, but not in Cloud Security Scanner,
use the feedback option within the tools to request support.
One possible workaround is to create a simplified alternative login form for the purposes of using the scanner if it's unable to work with the current one.
I am trying to implement delegated authorization in a Web API for mobile apps using OAuth 2.0. According to specification, the implicit grant flow does not support refresh tokens, which means once an access token is granted for an specific period of time, the user must grant permissions to the app again once the token expires or it is revoked.
I guess this is a good scenario for some javascript code running on a browser as it is mentioned in the specification. I am trying to minimize the times the user must grant permissions to the app to obtain a token, so it looks like the Authorization Code flow is a good option as it supports refresh tokens.
However, this flow seems to rely heavily on a web browser for performing the redirections. I am wondering if this flow is still a good option for a mobile app if a embedded web browser is used. Or should I go with the implicit flow ?
Clarification: Mobile App = Native App
As stated in other comments and a few sources online, implicit seems like a natural fit for mobile apps, however the best solution is not always clear cut (and in fact implicit is not recommended for reasons discussed below).
Native App OAuth2 Best Practises
Whatever approach you choose (there are a few trade offs to consider), you should pay attention to the best practices as outlined here for Native Apps using OAuth2: https://www.rfc-editor.org/rfc/rfc8252
Consider the following options
Implicit
Should I use implicit?
To quote from Section 8.2 https://www.rfc-editor.org/rfc/rfc8252#section-8.2
The OAuth 2.0 implicit grant authorization flow (defined in Section 4.2 of OAuth 2.0 [RFC6749]) generally works with the practice of performing the authorization request in the browser and receiving the authorization response via URI-based inter-app communication.
However, as the implicit flow cannot be protected by PKCE [RFC7636] (which is required in Section 8.1), the use of the Implicit Flow with native apps is NOT RECOMMENDED.
Access tokens granted via the implicit flow also cannot be refreshed without user interaction, making the authorization code grant flow --
which can issue refresh tokens -- the more practical option for native app authorizations that require refreshing of access tokens.
Authorization Code
If you do go with Authorization Code, then one approach would be to proxy through your own web server component which enriches the token requests with the client secret to avoid storing it on the distributed app on devices.
Excerpt below from: https://dev.fitbit.com/docs/oauth2/
The Authorization Code Grant flow is recommended for applications that
have a web service. This flow requires server-to-server communication
using an application's client secret.
Note: Never put your client secret in distributed code, such as apps
downloaded through an app store or client-side JavaScript.
Applications that do not have a web service should use the Implicit
Grant flow.
Conclusion
The final decision should factor in your desired user experience but also your appetite for risk after doing a proper risk assessment of your shortlisted approaches and better understanding the implications.
A great read is here https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
Another one is https://www.oauth.com/oauth2-servers/oauth-native-apps/ which states
The current industry best practice is to use the Authorization Flow
while omitting the client secret, and to use an external user agent to
complete the flow. An external user agent is typically the device’s
native browser, (with a separate security domain from the native app,)
so that the app cannot access the cookie storage or inspect or modify
the page content inside the browser.
PKCE Consideration
You should also consider PKCE which is described here https://www.oauth.com/oauth2-servers/pkce/
Specifically, if you are also implementing the Authorization Server then https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ states that you should
Allow clients to register custom URL schemes for their redirect URLs.
Support loopback IP redirect URLs with arbitrary port numbers in order to support desktop apps.
Don’t assume native apps can keep a secret. Require all apps to declare whether they are public or confidential, and only issue client secrets to confidential apps.
Support the PKCE extension, and require that public clients use it.
Attempt to detect when the authorization interface is embedded in a native app’s web view, instead of launched in a system browser, and reject those requests.
Web Views Consideration
There are many examples in the wild using Web Views i.e. an embedded user-agent but this approach should be avoided (especially when the app is not first-party) and in some cases may result in you being banned from using an API as the excerpt below from here demonstrates
Any attempt to embed the OAuth 2.0 authentication page will result in
your application being banned from the Fitbit API.
For security consideration, the OAuth 2.0 authorization page must be
presented in a dedicated browser view. Fitbit users can only confirm
they are authenticating with the genuine Fitbit.com site if they have
the tools provided by the browser, such as the URL bar and Transport
Layer Security (TLS) certificate information.
For native applications, this means the authorization page must open
in the default browser. Native applications can use custom URL schemes
as redirect URIs to redirect the user back from the browser to the
application requesting permission.
iOS applications may use the SFSafariViewController class instead of
app switching to Safari. Use of the WKWebView or UIWebView class is
prohibited.
Android applications may use Chrome Custom Tabs instead of app
switching to the default browser. Use of WebView is prohibited.
To further clarify, here is a quote from this section of a previous draft of the best practise link provided above
Embedded user-agents, commonly implemented with web-views, are an
alternative method for authorizing native apps. They are however
unsafe for use by third-parties by definition. They involve the user
signing in with their full login credentials, only to have them
downscoped to less powerful OAuth credentials.
Even when used by trusted first-party apps, embedded user-agents
violate the principle of least privilege by obtaining more powerful
credentials than they need, potentially increasing the attack surface.
In typical web-view based implementations of embedded user-agents, the
host application can: log every keystroke entered in the form to
capture usernames and passwords; automatically submit forms and bypass
user-consent; copy session cookies and use them to perform
authenticated actions as the user.
Encouraging users to enter credentials in an embedded web-view without
the usual address bar and other identity features that browsers have
makes it impossible for the user to know if they are signing in to the
legitimate site, and even when they are, it trains them that it's OK
to enter credentials without validating the site first.
Aside from the security concerns, web-views do not share the
authentication state with other apps or the system browser, requiring
the user to login for every authorization request and leading to a
poor user experience.
Due to the above, use of embedded user-agents is NOT RECOMMENDED,
except where a trusted first-party app acts as the external user-
agent for other apps, or provides single sign-on for multiple first-
party apps.
Authorization servers SHOULD consider taking steps to detect and block
logins via embedded user-agents that are not their own, where
possible.
Some interesting points are also raised here: https://security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the-a
Unfortunately, I don't think there is a clear answer to this question. However, here are the options that I've identified:
If it is ok to ask the user for his/her credentials, then use the Resource Owner Password Credentials. However, this may not be possible for some reasons, namely
Usability or security policies forbid the insertion of the password directly at the app
The authentication process is delegated on an external Identity Provider and must be performed via an HTTP redirect-based flow (e.g. OpenID, SAMLP or WS-Federation)
If usage of a browser based flow is required, then use the Authorization Code Flow. Here, the definition of the redirect_uri is a major challenge, for which there are the following options:
Use the technique described in https://developers.google.com/accounts/docs/OAuth2InstalledApp, where a special redirect_uri (e.g. urn:ietf:wg:oauth:2.0:oob) signals the authorization endpoint to show the authorization code instead of redirecting back to the client app. The user can manually copy this code or the app can try to obtain it from the HTML document title.
Use a localhost server at the device (the port management may not be easy).
Use a custom URI scheme (e.g. myapp://...) that when dereferenced triggers a registered "handler" (the details depend on the mobile platform).
If available, use a special "web view", such as the WebAuthenticationBroker on Windows 8, to control and access the HTTP redirect responses.
Hope this helps
Pedro
TL;DR: Use Authorization Code Grant with PKCE
1. Implicit Grant Type
The implicit grant type is quite popular with mobile apps. But it was not meant to be used like this. There are security concerns around the redirect. Justin Richer states:
The problem comes when you realize that unlike with a remote server
URL, there is no reliable way to ensure that the binding between a
given redirect URI and a specific mobile application is honored. Any
app on the device can try to insert itself into the redirection
process and cause it to serve the redirect URI. And guess what: if
you’ve used the implicit flow in your native application, then you
just handed the attacker your access token. There’s no recovery from
that point — they’ve got the token and they can use it.
And together with the fact, that it does not let you refresh the access token, better avoid it.
2. Authorization Code Grant Type
The authorization code grant requires a client secret. But you should not store sensitive information in the source code of your mobile app. People can extract them. To not expose the client secret, you have to run a server as a middleman as Facebook writes:
We recommend that App Access Tokens should only be used directly from
your app's servers in order to provide the best security. For native
apps, we suggest that the app communicates with your own server and
the server then makes the API requests to Facebook using the App
Access Token.
Not an ideal solution but there is new, a better way to do OAuth on mobile devices: Proof Key for Code Exchange
3. Authorization Code Grant Type with PKCE (Proof Key for Code Exchange)
Out of the limitations, a new technique was created that let you use the Authorization Code without a client secret. You can read the full RFC 7636 or this short introduction.
PKCE (RFC 7636) is a technique to secure public clients that don't use
a client secret.
It is primarily used by native and mobile apps, but the technique can
be applied to any public client as well. It requires additional
support by the authorization server, so it is only supported on
certain providers.
from https://oauth.net/2/pkce/
Using a webview in your mobile application should be an affordable way to implement OAuth2.0 protocol on Android platform.
As for redirect_uri field, I think http://localhost is a good choice and you don't have to port a HTTP server inside your application, because you can override the implementation of onPageStarted function in the WebViewClient class and stop loading the web page from http://localhost after you check the url parameter.
public void onPageStarted(final WebView webView, final String url,
final Bitmap favicon) {}
The smoothest user experience for authentication, and the easiest to implement is to embed a webview in your app. Process the responses received by the webview from the authentication point and detect error (user cancel) or approval (and extract token from url query parameters).
And I think you can actually do that in all platforms. I have successfully made this work for the following: ios, android, mac, windows store 8.1 apps, windows phone 8.1 app. I did this for the following services: dropbox, google drive, onedrive, box, basecamp. For the non-windows platforms, I was using Xamarin which supposedly does not expose the entire platform specific APIs, yet it did expose enough for making this possible. So it is a pretty accessible solution, even from a cross platform perspective, and you don't have to worry about the ui of the authentication form.
I am developing a chrome plugin which allows the users to email any web content from a html page. For that, I need to use the google authenticator api to allow users to log into their google accounts for sending emails. The OAuth2.0 specs require the redirect_ui parameter which is the url to be called after google authenticates the user. My question is whether it is possible to skip this parameter. I don't want the plugin to be hosted anywhere. I am thinking that it would be hosted locally on the user's machine.
Thanks in Advance.
Google has made a library specifically for using OAuth in Chrome extensions. You can check out the tutorial here.
In case someone stumbles upon this answer in 2017+, extensions (in Chrome and FF) now have a chrome.identity API.
It takes care of the OAuth dance for you, and provides you with a virtual redirect address https://<your-extension-id>.chromiumapp.org/ that will be intercepted by the browser. That way, you can provide a redirect URL without hosting anything.