We are using Go server side code to interact with Google Ads REST API.
Namely, we authenticate it with help of "golang.org/x/oauth2" and
"golang.org/x/oauth2"packages.
In May (and recently again) we've got a email from Google regarding deprecation
Out-of-band flow, essentially rewording of this
one.
But additionally to common information, Google email listed account, which we
are using to authenticate, as being used in OOB flow and going to be blocked.
We checked our sources and available sources of mentioned packages but was not
able to find redirect URIs which are said to be used for OOB flow as one of
those:
redirect_uri=urn:ietf:wg:oauth:2.0:oob
urn:ietf:wg:oauth:2.0:oob:auto
oob
We explicitly use http://localhost in our code and long-live refresh token
(which seems never expires).
We also tried to use tcpdump to monitor our API calls, but was not able to
learn much from it, because calls are made via https and, therefore, encrypted.
We considered to use man-in-the-middle kind of proxy like
https://www.charlesproxy.com/, but haven't tried it yet, because it become
non-free and because of complexity of setup.
We tried to log our requests to API endpoint with custom RoundTripper, but
have not spotted anything suspicious. It seems that we're using refresh token
only and exchange of code to refresh token just never happen in the code.
Because of this, we don't think that further logging or monitoring with
decrypting https packages may help (but we open to suggestions how to do it better).
Finally, we decided to create a new OAuth 2 Client in the Google console with
fresh set of client id, client secret and refresh token. We obtained a new
refresh token with oauth2l and replaced
credentials in our configuration. But still, we are not sure that new account
will not be blocked by Google due OOB deprication, because seemingly it looks
the same as old one.
Questions:
Why may Google mark our account as OOB?
How can we ensure that newly created account will not be blocked?
Same here.
I find out an answer, that says "Desktop" type of Credentials uses OOB by default. Probably you need to create new Credentials with type "Web"
This question is kinda complimentary to "Share credentials between native app and web site", as we aim to share secrets in the opposite direction.
TL;TR: how can we securely share the user's authentication/authorization state from a Web Browser app to a Native Desktop app, so the same user doesn't have to authenticate additionally in the Native app?
TS;WM: We are working on the following architecture: a Web Application (with some HTML front-end UI running inside a Web Browser of user's choice), a Native Desktop Application (implementing a custom protocol handler), a Web API and an OAuth2 service, as on the picture.
Initially, the user is authenticated/authorized in the Web Browser app against the OAuth2 service, using the Authorization Code Grant flow.
Then, the Web Browser content can do one-way talking to the Native app, when the user clicks on our custom protocol-based hyperlinks. Basically, it's done to establish a secure bidirectional back-end communication channel between the two, conducted via the Web API.
We believe that, before acting upon any requests received via a custom protocol link from the Web Browser app, the Native app should first authenticate the user (who is supposed to be the same person using this particular desktop session). We think the Native app should as well use the Authorization Code flow (with PKCE) to obtain an access token for the Web API. Then it should be able to securely verify the origin and integrity of the custom protocol data, using the same Web API.
However, it can be a hindering experience for the user to have to authenticate twice, first in the Web Browser and second in the Native app, both running side-by-side.
Thus, the question: is there a way to pass an OAuth2 access token (or any other authorization bearer) from the Web Browser app to the Native app securely, without compromising the client-side security of this architecture? I.e., so the Native app could call the Web API using the identity from the Web Browser, without having to authenticate the same user first?
Personally, I can't see how we can safely avoid that additional authentication flow. Communication via a custom app protocol is insecure by default, as typically it's just a command line argument the Native app is invoked with. Unlike a TLS channel, it can be intercepted, impersonated etc. We could possibly encrypt the custom protocol data. Still, whatever calls the Native app would have to make to decrypt it (either to a client OS API or some unprotected calls to the Web API), a bad actor/malware might be able to replicate those, too.
Am I missing something? Is there a secure platform-specific solution? The Native Desktop app is an Electron app and is designed to be cross-platform. Most of our users will run this on Windows using any supported browser (including even IE11), but ActiveX or hacking into a running web browser instance is out of question.
The best solution : Single Sign On (SSO) using Custom URL Scheme
When I was checking your question, I remembered the Zoom app that I am using in my office. How it works ?
I have my Gmail account linked to a Zoom account (this is account linkage, which is outside the scope of implementation). When I open Zoom app, I can choose the option to login with Gmail. This opens my browser and take me to Gmail. If I am logged in to Gmail, I am redirected back to a page that asking me to launch Zoom app. How this app launch happen ? The application register a custom URL scheme when app get installed and the final redirect in browser targets this URL. And this URL passes a temporary secret, which Zoom application uses to obtain OAuth tokens. And token obtaining is done independent of the browser, a direct call with SSL to token endpoint of OAuth server.
Well this is Authorization code flow for native applications. And this is how Mobile applications use OAuth. Your main issue, not allowing user to re-login is solved. This is SSO in action.
There is a specification which define best practices around this mechanism. I welcome you to go through RFC8252 - OAuth 2.0 for Native Apps.
Challenge
You need to implement OS specific native code for each application distribution. Windows, Mac and Linux have different implementation support for custom URL scheme.
Advice
PKCE is mandatory (in IETF words SHOULD) for all OAuth grant types. There is this ongoing draft which talks about this. So include PKCE for your implementation too.
With PKCE, the redirect/callback response is protected from stealing. Even some other application intercept the callback, the token request cannot be recreated as the PKCE code_verifer is there.
Also, do not use a custom solution like passing secret through another channel. This will make things complicated when it comes to maintenance. Since this flow already exists in OAuth, you can benefit with libraries and guidance.
-----------------------------------------------------
Update : Protecting Token Request
While the custom URL scheme solves the problem of launching the native application, protecting token request can be challenging. There are several options to consider.
- Bind native application launch with a secret shared from browser
When browser based client launch the native client, it can invoke a custom API to generate a secret. This secret acts like a one time password (OTP). User has to enter this value in native app before it obtain tokens. This is a customization on top of Authorization code flow.
- Dynamic client registration & Dynamic client authentication
Embedding secrets into public clients is discouraged by OAuth specification. But as question owner points out, some malicious app may register itself to receive custom URL response and obtain tokens. In such occasion, PKCE can provide an added layer of security.
But still in an extreme case, if malicious app registers the URL plus use PKCE as the original application, then there can be potential threats.
One option is to allow dynamic client registration at the first time of application launch. Here, installer/distribution can include a secret that used along with DCR.
Also, it is possible to use dynamic client authentication through a dedicated service. Here, the application's token request contains a temporary token issued by a custom service. Custom service obtain a challenge from native application. This may be done through totp or a cryptographic binding based on an embedded secret. Also it is possible to utilize OTP (as mentioned in first note) issued through browser, which needs to be copy pasted manually by end user. Once validated, this service issue a token which correlate to the secret. In the token request, native client sends this token along with call back values. This way we reduce threat vectors even though we increase implementation complexity.
Summary
Use custom URL scheme to launch the native application
Browser app generate a temporary secret shared with a custom service
At native app launch, user should copy the secret to native app UI
Native app exchange this secret with custom service to obtain a token
This second token combined with call back authorization code (issued through custom url scheme) is used to authenticate to token endpoint
Above can be considered as a dynamic client authentication
Value exposed to user can be a hashed secret, hence original value is never exposed to end user or another client
DCR is also an option but embedded secrets are discouraged in OAuth world
As you mentioned, using a custom protocol handler is not a safe way to pass secrets, since another app may handle your protocol and intercept that secret.
If you are imposing a strict constraint that the communication channel between the native app and the web app is initiated from the web app, and that the native app has not previously established a secure channel (e.g. shared secret which could encrypt other secrets), then it is not possible to safely transmit a secret to the native app.
Imagine if this were possible, then PKCE would be redundant in an OAuth 2.0 Code Flow, since the server could have safely transmitted the access token in response to the authorization request, instead of requiring the code_verifier to be provided with the grant when obtaining the access token.
Just got the following idea. It's simple and while it doesn't allow to fully automate the setup of a secure channel between Web Browser app and the Native app, it may significantly improve the user experience.
We can use Time-based One-Time Password algorithm (TOTP). In a way, it's similar to how we pair a Bluetooth keyboard to a computer or a phone.
The Web Browser app (where the user is already authenticated) could display a time-based code to the user, and the Native app should ask the user to enter that code as a confirmation. It would then use the code to authenticate against the Web API. That should be enough to establish a back-end channel between the two. The life time of the channel should be limited to that of the session within the Web Browser app. This approach might even eliminate the need for a custom protocol communication in the first place.
Still open to other ideas.
You could try driving the synchronization the other way:
Once the user is authenticated into the web app, launch the native app from the web app via the custom URL scheme.
If the native app is not authenticated, connect securely to the backend over HTTPS, create a record for the native app, retrieve a one time token associated with that record and then launch the web app in the user's browser with the token as a URL parameter.
Since the user is authenticated in the browser, when the server sees the token it can bind the native app's record with the user account.
Have the native app poll (or use some other realtime channel like push notifications or a TCP connection) the server to see if the token has been bound to a user account: once that happens you can pass a persistent auth token that the native app can store.
Did you think about using LDAP or Active Directory?
Also OAuth2 could be combined, here are a related question:
- Oauth service for LDAP authentication
- Oauth 2 token for Active Directory accounts
SSO should be easier then too, furthermore access-rights could be managed centralized.
Concerning general security considerations you could work with two servers and redirect form the one for the web-application to the other one after successful access check. That 2nd server can be protected so far that a redirect is required from the 1st server and an access check could be made independent again but without need to login another time, might be important to mention here the proposed usage of Oracle Access Manager in one linked answer for perimeter authentication.
This scenario with two servers could be also hidden by using a proxy-server in the frontend and making the redirects hidden, like that data-transfer between servers would be easier and secure too.
The important point about my proposition is that access to the 2nd server is just not granted if anything is wrong and the data are still protected.
I read here some comments concerning 2FA and some other ideas like tokens, surely those things increase security and it would be good to implement them.
If you like the general idea, I'm willing to spend still some time on the details. Some questions might be helpful for me ;-)
EDIT:
Technically the design in detail might depend on the used external authentication provider like Oracle Access Manager or something else. So if the solution in general sounds reasonable for you it would be useful to elaborate some parameters for the choice of a external authentication provider, i.e. price, open-source, features, etc.
Nevertheless the general procedure then is that the provider issues a token and this token serves for authentication. The token is for unique one-time usage, the second link I posted above has some answers that explain token-usage very well related to security and OAuth.
EDIT2
The Difference between an own OAuth2 / OIDC server and a LDAP/AD server is that you need to program everything by yourself and can't use ready solutions. Nevertheless you're independent and if everything is programmed well perhaps even a bit more secure as your solution is not public available and therefore harder to hack - potential vulnerabilities just can't be known by others. Also you're more independent, never have to wait for updates and are free to change whatever you want at any time. Considering that several software-servers are involved and perhaps even hardware-servers the own solution might be limited scale-able, but that can't be know from outside and depends on your company / team. Your code base probably is slimmer than full-blown solutions as you've only to consider your own solution and requirements.
The weak point in your solution might be that you have to program interfaces to several things that exist ready for business-frameworks. Also it might be hard to consider every single point in a small team, large companies could have more overview and capacity to tackle every potential issue.
I am writing an app that uses Parse Server, with Auth0 as the authentication provider. For unrelated reasons, we need to use Auth0 rather than Parse for user management.
I'm having trouble figuring out how to "link" a user authenticated via Auth0 to Objects in Parse Server. Without this, the authenticated user will not have permission to write to his/her Objects on the Parse Server. I believe my issue is similar to this question, which has no solution: here.
I have found many articles discussing the migration of users from Parse to Auth0, but am finding surprisingly little documentation on how to link those users to Parse. There is one article (I believe written by the same person who posted the question I linked to), but I couldn't get it to work, and it involves storing passwords in cleartext in Javascript.
I thought to create a default Parse user that would simply own all the objects in Parse. This would be invisible to the authenticated end-user so they wouldn't know, but that's just security by obscurity and doesn't seem like a good approach.
If anyone has suggestions on how to approach this, or has done it before, I'm interested to read your suggestions. Thank you very much.
Auth0 supports the most common and used authentication protocols (OAuth2/OIDC, SAML and WS-Federation) so configuring an application to rely on Auth0 is really easy when that application already talks one of the previously mentioned protocols.
According to the Parse Server Wiki, it does support custom authentication leveraging OAuth so that seems your best starting point for integrating Auth0 with a Parse Server based application.
It is possible to leverage the OAuth support with any 3rd party authentication that you bring in.
Disclaimer: I never used the Parse service or Parse Server so I'm assuming that when you mean linking Parse objects to users this can be accomplished by simply having an authenticated user in Parse and the identity of that user is just verified and proven by Auth0 instead of something like built-in username/passwords managed by Parse itself.
As part of an application my users can create documents with embedded images/files/text etc. Viewing and editing this content requires the user to log in. At the moment the images and files though are delivered as permanent links so if those links are shared any non-authenticated user can access them forever.
I would like to make these files secure. My initial thought was to use the login token and user's id to check if they have access and only deliver the files if they do. But then I started working on it and it seems the most practical solution would involve generating a link that will expire at some point in the future. This doesn't remove the exposure to unauthenticated access but maybe reduces it enough.
The questions that come to mind are:
Is there a common approach or a few options on how this should be implemented?
I've seen returning urls with expiration periods used
Google docs seems to do something more sophisticated for it's embedded images but I can't tell what
Others?
Basic design points?
Pros/Cons of each?
Yes, it reduces the authenticated access to a fixed time but theoretically it provides un-authenticated access. So a security professional will claim it has no authentication. This kind of timed expiry link is usually used to safeguard against one time un-authenticated access like password reset(along with an expiring token independent from the time).
What is your goal? From whom are you trying to protect the data? Is the users who already have access to files and you want to limit providing an expiry time? From the question, you need to secure the access to the files/documents which has text and embedded images in it from everyone. You are right about the timed expiry design. It will not guarantee you authentication and integrity of the document and if it is over non-secure HTTP it will not even provide you integrity of the document from a potential adversary.
you can use cookies(secure cookie) over HTTPS. As long as the user has the non-expired cookie, allow access to the files/documents. The cookie approach needs distributed cookie management if you to host the solution in multiple boxes with a reverse proxy in-front. Though cross-site scripting is a threat but still most of major web application providers are using cookie based solutions. Please note, cookie breaks the REST nature of the web-application.
Another approach (similar to cookie) is to generate authenticated tokens tied to user/documents which has access for N number of attempts for a time period set while generating the token. This method has to be used over HTTPS to avoid un-wanted listeners.
An always changing link is very costly to manage and not scalable over time because it is too much state to manage and application crash makes it even more costly. Re-directing to authentication is a safe bet for you provided you have already cookie management in place or you have one application instance to take care of.
Or you can you HTTP digest authentication provided that your framework supports it so that you do not have to worry about the cookie-hell. Please note that you may need to write up some client-side java script based on your use case.
I am trying to integrate two separate web applications - one is an existing custom web application with it's own security paradigm and the other is a reporting platform (JasperServer). I want to be able to use Jasper's web services interface to integrate the reporting functionality into our application. Our security model is complex and is home grown but I think there is hope.
We set a cookie that is an encrypted string containing a web service URI as the authentication source and a token which is stored in the database that is created when the user logs in and is destroyed when he/she logs out. I think I can leverage this to implement a kind of SSO in Jasper since it uses Spring Security.
What I THINK I should do is implement a pre-authentication filter that checks for the cookie I mentioned above. It could then decrypt it, make a web service call to the authentication source provided to verify the token is active in the database. If it is, that token can be used to point to user and role information that could be returned as a UserDetails object.
Unfortunately, I know enough to be dangerous but not enough to be effective. Am I on the right track? Does this solution sound tenable? If so, where would be a good place to start and are there any examples of something similar you could point me to? I've searched around quite a bit and have found nothing that quite fits the bill.
Thanks in advance to any and all who can provide me a glimmer of hope
Cookies are tied to a domain/subdomain/path and port. It is possible to set a cookie at the domain level so if you have something like webapp.mydomain.com and jasper.mydomain.com you may be ok assuming they are on the same port.
However be very careful about implementing your own SSO/Authentication framework. It requires a great deal of thought. As it stands your proposed implementation would be vulnerable to: replay, man in the middle, and XSRF attacks ... there may be other vulnerabilities but these are just 3 that come to mind ... sorry! :D