How to obtain oauth access tokens from google if i have only registered app and no server to redirect (as a "redirect_uri" parameter)?
I'm guessing that when you say you have no server, that your app is a native app. eg a desktop app or an embedded app. If so, you can generate tokens using the OAUth playground. See How do I authorise an app (web or installed) without user intervention? (canonical ?) for details.
You can use https://www.example.com/oauth2callback as your redirect uri.
Yes you can get an access token without a server. We've made it fairly easy. See the docs
On android it is fairly easy
https://developers.google.com/identity/sign-in/android/additional-scopes
https://developers.google.com/identity/sign-in/ios/
https://developers.google.com/identity/sign-in/ios/additional-scopes
Web
https://developers.google.com/identity/sign-in/web/incremental-auth
You can just change the scopes you need.
Related
The context:
I'm trying to develop a desktop app with ElectronJS which needs access to Google APIs. As such, I want my users to be able to connect to their Google account via OAuth2.
As I use Electron, I have no safe way to store a "client-secret" and must use the "mobile app" method.
The problem:
Google keeps rejecting my redirect_uri:
The doc I followed:
The official npm "google-auth-library" package mentions the following regarding OAuth authentication for Electron apps ("OAuth2 with Installed Apps (Electron)" section) :
If you're authenticating with OAuth2 from an installed application (like Electron), you may not want to embed your client_secret inside of the application sources. To work around this restriction, you can choose the iOS application type when creating your OAuth2 credentials in the Google Developers console
As doing so gave me the previously mentionned Error 400, I looked into Google Identity documentation and saw this regarding localhost redirection:
Note that support for the loopback IP address redirect option on mobile apps is DEPRECATED.
My question:
At this point, I suspect that this is the reason Google is responding Error 400 to my requests (but I admit it could be my fault. I just don't understand what I do wrong as I feel like I follow the documentation strictly.)
If so, what are the possible ways to solve the issue ? Knowing that I have strictly 0 budget for this project and so I cannot afford to redirect to a domain I would buy or afford a server acting as proxy between my app and Google APIs.
(The code, if useful)
I use the "complete OAuth2 example" from google-auth-library except I changed the OAuth2Client constructor call to this, following the doc's recommandations:
const oAuth2Client = new OAuth2Client({
clientId: "<the clientID of my project from Google API Console>",
redirectUri: "http://127.0.0.1:3000"
})
In despair, I've tried a whole lot of different URL formats, but nothing works.
Thanks in advance for your help.
OAUTH BEHAVIOUR
An OpenID Connect desktop app uses PKCE without a client secret. According to RFC8252 it then receives the login response on either a loopback URL or via a private URI scheme notification.
The loopback option is fine for a desktop app but should not be used for a mobile app. Conversely, claimed HTTPS redirect URLs work for mobile apps but not desktop apps.
TROUBLESHOOTING YOUR PROBLEM
It is not clear whether your problem is caused by using a loopback URL or something else. To troubleshoot, you can use a couple of demo Electron apps of mine:
Loopback example
Private URI Scheme example
In both cases, edit the desktop.config.json file in the root folder. Replace my AWS Cognito values with your Google values. Then run npm start. See if that gets you any further, and post any follow up questions.
I'm working on a project that's trying to include microsoft sign in, in order to use information about the person that signed in.
I'm doing this as a node js app that's run from my local machine, and there is no webpage / web server involved.
Mainly wondering if it's possible to sign in with a microsoft account without having to use a browser, or getting a URL link to sign in with, and then a way for me to get the access token without needing a redirect link back to a page.
It sounds like device code flow might meet your requirements.
Documentation for device code flow: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code
MSAL Node sample showing device code flow: https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-node-samples/standalone-samples
There is also username/password flow, but that is not recommended, and MSAL Node does not support it yet. https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
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.
Might seem a silly question, but Microsoft's documentation isn't very beginner friendly, I think. It uses as examples "http://localhost:31544" for the sign-on url and "http://MyFirstAADApp" for the redirect URI, but although I understand what a local host is I can't figure out what exactly the numbers on it are and how I define them for my application, and absolutely zero clue of what the redirect URI is supposed to do for a native application and how should I define a URI for my own.
To be more clear on what kind of app I'm trying to add, I merely want to acess the Office 365 management API tools and get some data from it, so I imagine a native app would fulfill my needs for now. Registering the app on Azure AD is required to do so according to Microsoft's documentation.
So expanding on the title, how to define an URI for my native app is what I would mainly like to know. Some further clarification on what exactly is the purpose of this URI as well as to how to use and/or define a localhost URL for an Web app would also be much appreciated.
I know this is ancient, but I don't see a satisfying answer here, and maybe someone will come across this and find it useful. To answer the question asked, unless you're going to work outside of the default MSAL handling of the server responses, and I don't expect you would from your description, I'd just go ahead and use the default:
https://login.microsoftonline.com/common/oauth2/nativeclient
When you go into the Azure AD portal, go to your application and, from the Overview, select the "Set RedirectURL" option, you'll add a platform and select the "Mobile and Desktop Applications" and you'll be provided with the choice of 3 URLs to choose from. My understanding is this is just there for custom handling of authorization tokens and is telling MS where to send those tokens. The MSAL library functions seem to use this link as well, so they're probably handling this in the backend.
I agree with the OP though, the MS docs are severely lacking for newcomers and I wasn't able to find an end-to-end description of what needs to happen to get, in my case, a desktop application to send email through Office365 using 2FA. I would forge ahead as best I could until I hit the next error, then explore that, sort it, then slam into the next one. Rinse and repeat. This was made extra tedious as I had to go through a 3rd party IT group to get the 2FA access codes every time I wanted to test.
Best of luck, hope this helps someone!
how to define an URI for my native app is what I would mainly like to
know.
You should provide a Redirect URI that is unique to your application as it will return to this URI when authentication is complete.
In your application, you will need to add a class level variables that are required for the authentication flow, include ClientId and Redirect URI.
Here is the diagram:
Native application makes a request to the authorization endpoint in Azure AD, this request includes the Application IP ,Redirect URI and application ID URI for the web api.
After user signed in, Azure AD issues an authorization code response back to the client application's redirect URI. After that, the client application stops browser interaction and extracts the authorization code from the response.
Then the client app use this code to sends a request to Azure AD's token endpoint. upon successful validation, Azure AD returns two tokens.
Over HTTPS, the client app uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. The web API then validates the JWT token, and if validation is successful, returns the desired resource.
More information about it, please refer to this article.
For native you can set redirect to be equal to the Application ID URI, which now defaults to look like //app:{ApplicationId}
Redirect uri be starts with SSL URL, so select your project, enable SSL URL and use this auto generated SSL URL (for example : https://localhost:port#) as redirect uri , same to be updated in the azure app registration as additional redirect URIs
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.