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.
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 have a nodejs webapp with many users with a custom login process. I would like gitlab to accept that authentication and not force users to create a new app. What is the best way to accomplish this?
I would go for OAuth 2.0 Single Sign On (SSO). Below you can find the architecture diagram taken from here. As you can see the client is redirected to log in in the OAuth2 provider to get a valid token for authentication. The OAuth2 server must be configured for the application requesting access including the secret, the client id and the callback URL.
You can configure GitLab CE to sign in with almost any OAuth2 provider. Only be careful with the limitations:
It can only be used for Single Sign on, and will not provide any other access granted by any OAuth provider (importing projects or users, etc)
It only supports the Authorization Grant flow (most common for client-server applications, like GitLab)
It is not able to fetch user information from more than one URL
It has not been tested with user information formats other than JSON
You also need to configure your node js web application as an OAuth2 server. There are npm availables with the source code here.
Recommendation
I would install some open source Identity Management to separate the user management from your webapp, provides better integration with other third parties and forget about encryption and other stuff you need to take care in your webapp. There are multiple options such as KeyCloak for instance.
You have to define a dedicated user , and use the private_token of this user to login for ALL users that will use your application.
The restricition would imply all users will have the same rights ....
The other solution is to use the Private Token of the user at login. In this case , only the rights of these particular users will be used.
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/
With web based applications running in Chrome, I have been able to leverage Chrome to negotiate passing local credentials via SPNEGO. In the XMLHttpRequest, we set the option pass withCredentials. It seems like the http module in nodejs/electron does not have this capability.
Has anyone been able to pass the credentials of the currently logged in Windows user using the http module in electron? I am looking to make calls to some internal web services that require authentication and I don't want to force the user to enter login credentials again.
I'm working on creating an app that will provide authentication using the OAuth2 protocol to serve known clients using the app's Strategy.
I have tried using both the oauth2orize, and node-oauth2-provider modules, and I keep getting the to same point:
User logs in through client, api key and api secret are verified, and the user can successfully log in through my provider app.
After the client app, and the user successfully authenticate, a token is sent back to the client app (user is logged in the client - yay!), but the user is immediately logged out on the Provider app. I cannot figure out where, and why this happens - is this a feature of the OAuth2 protocol?
Is this normal? If I use Facebook as a strategy (think passport-facebook), then if I log in to any app using Facebook, I am still logged into Facebook when I'm redirected back to the app - this is the behavior I want to provide clients accessing my app.
Both Provider modules are great at doing 90% of what I'm looking for, but neither provide the "persistent" login in their examples, oauth2orize, and node-oauth2-provider. Am I missing something?
Um, I think I got it.
I was running both the client and server on localhost, using different ports - and cookies/sessions were overwriting each other.
So if client express app was running on http://localhost:3000 and oauth provider was running on http://localhost:3001, logging into the oauth provider and creating a session on the client was overwriting the session on the provider.
Solution (for now):
# /etc/hosts
127.0.0.1 dev.client.com
127.0.0.1 dev.oauth-provider.com
Logging in to http://dev.client.com:3000 takes me to http://dev.oauth-provider.com:3001 and when a user successfully logs in and a session is created on client, provider is still logged in.