I have been using Universal Login with Auth0. I would like to personalise the login experience for my users, so I'm considering switching to an embedded login form and using the SDK to authenticate with my auth0 server.
I only have one application, and potentially a native mobile app in future.
Reading the docs on Cross-Origin authentication it seems to suggest that the main issues here are:
Security risks with sending credentials cross-origin and open up the risk of a phising attack
Some browsers disable 3rd party cookies by default
And it would seem that both of these issues are solved by simply hosting my Auth0 server on the same domain as my embedded login form:
e.g auth.mydomain.com and mydomain.com/login
But still the Auth0 docs strongly advise using their Universal Login, almost every piece of documentation urges it.
My question
Are there any further issues with an embedded login form that sends credentials to an auth0 server on the same domain? When im only developing one application, I have no need for a shared login form.
Are auth0 just encouraging the use of Universal Login for business reasons?
Related
Disclaimer: hope this is not against the guidelines here, I also asked this question in the Keycloak forums https://keycloak.discourse.group/t/sso-impossible-from-direct-grant-app-to-redirected-app/319
I have been wrapping my head around this problem and I suspect that it’s not possible, so I'm seeking confirmation or infirmation.
I have 2 apps, which we will call “origin” and “destination”. I need to enable SSO navigation from “origin” to “destination”. Both use the same Keycloak instance (with OAuth, not SAML2).
This would be easy if both apps used redirection... but they don’t, “origin” uses direct grant access.
The end-user logs in to “origin” by providing directly login + password to the app UI, the UI establishes a WebSocket with its backend and uses it to send the user credentials, the backend calls the Keycloak API with login + password and gets tokens for all further operations (API access).
There is one session per WebSocket, the UI never ever knows about tokens or Keycloak but just calls the backend that has the tokens, and when the user logs out the WebSocket is closed and the backend container is destroyed.
“Destination” is more classic, it uses Keycloak normally with redirection.
I want the user to be able to navigate to “destination” without being asked for credentials.
From what I’ve found online, this seems impossible. Refs:
https://lists.jboss.org/pipermail/keycloak-dev/2016-January/006349.html
https://keycloak.discourse.group/t/one-client-always-prompts-for-username-and-password-oidc/249/2
So my questions are...
is it possible?
could the “origin” app put its tokens in a cookie that would be found by the “destination” app, or more accurately by its Keycloak login UI?
could the “origin” app call some Keycloak API to inform it that “destination” app can be considered logged in with the same tokens? So that when the “destination” app tries to log in, Keycloak doesn’t even ask for credentials.
is there any other workaround? In the long term I could ask “origin” to use redirection, but a short term hack would be cool.
I should add that I’m not an authent expert. I have worked with SAML2 in the past so I understand the big picture.
Any help or advice appreciated :-)
This works: "origin" gets the JWT from the backend. It sets the JWT on the URL calling "destination", which uses it to say it's logged in. (the JWT is a URL param)
As a consequence both apps are seen as the same from the identity manager (Keycloak). But the user does not have to authenticate when arriving in "destination".
"destination" had to be slightly modified for this.
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 am currently developing an SPA application that connects to a bunch of webAPI's. These API require that the user is logged in, so I started digging into Openid Conect and OAuth2 examples, mostly using IdentityServer.
They all require, for SPA reasons, that the implicit grant should be used for retrieving access_tokens. Token refreshes are handled connecting to authentication server using hidden iframe.
What I understand from this approach o renewing your access_token is that, sessions is maintained at authentication service. Hidden iframe goes to the authentication server, sessions is still active, new access_token is provided.
All that looks good for me, except (for UX reasosn) the fact that my user needs to be redirected to authentication server page for providing credentials.
Isn't it possible to have my SPA application send credentials to authentication server, getting the access_token, and then do the refresh using the hidden iframe for silently renewing (we, obviously dont want the user to keep informing credentials every 15 minutes or every hour..).
If this is not acceptable for security reasons, could you please explain why?
Technically it is possible with "resource owner password flow", but in that model identity provider can not trust your application and will not create a session for your user (to use silent renew later on). Thus such non-interactive approach is not truly SSO. For 2019 the recommended flow for any web app such as Angular SPA is Code flow with PKCE extension, as described here or there.
EDIT:
Editing this answer to correctly reflect the requirement.
If the requirement is not to show authentication server page and use your own SPA, the only possible way to do it is using "Resource owner password flow" with the constraints mentioned in the previous answer
This is discouraged for two reasons:
Security - Will the SPA have the same security controls as the "Authentication server" has in handling passwords of the user. Right from collection to management of the user password (safely securing for future calls ?). This will massively impact the scope of SPA and it is one of the main reasons why people prefer federated logins (outsourcing login complexity to the third party - in your case authentications server)
Trust - How would you convince the user to handout the "authentication server" password to a relatively new SPA app. Imagine if Google / Facebook allows this pattern for a SPA to collect password instead of redirecting to the Google / Facebook login page. This is a recipe for disaster.
This is exactly what oidc-client-js library does. Have a look at automaticSilentRenew settings in their wiki page. Understandably this only works as long as the session at the authentication server is still active.
I use Google Webtoolkit together with Phonegap to build a mobile app. My app is communicating over a REST APi with my Backend Server.
What I want to do is a user authentication, i.e., my app user should be able to signup and login. If a user closes the app and reopens it, he should be authenticated again if he has not logged out before.
Usually, with Spring Security you do the authentication on the server by calling the required methods. The client (browser) then contains some cookie information for a persistent login.
1. How can achieve this kind of authentication for my app?
2. Should I do the authentication as for a normal web site with the only difference that the authentication methods are called by the REST api methods?
3. Is there another way of doing the authentication for my mobile app?
I think user authentication for the mobile app will be the same as for a normal web-app.
The Spring backend will create a session once a user is authenticated. By default the user is authenticated for the duration of the specific session (until the user closes the browser/app).
Spring Security has a Remember-me functionality that is typically based on a Cookie approach and allows the user to be re-authenticated automatically..
I don't know if phonegap work with Cookies (see here for some pointers). I guess it depends on the plattform (if webview supports cookies).
May be this will help you I wrote an article that show how to adapt Spring Security to secure REST services.
You can check it in here : http://crazygui.wordpress.com/2014/08/29/secure-rest-services-using-spring-security/
I also posted a working example which shows how I did use that with GWT on GitHub.
I'm currently planning a new web project. Clients are going to connect using a regular web browser and, in case of regular java-enabled cell phones, j2me client. I would really like to make use of the OpenID authentication. In case of regular web browser things are pretty straightforward. However, I am really not sure about installed applications (such as j2me client installed on a mobile device) - regular OpenID authentication is performed by entering username/password on a webpage of particular OpenID provider - which is quite a limitation :)
Has anyone coped with such a situation? Is it possible to create authentication mechanism to the site that uses OpenID from a mobile j2me client?
Currently, I think of solution that users who would like to connect from their mobiles download necessary j2me application from the server web site after they have authenticated themselves (regular browser authentication). The mobile client app could be assembled dynamically on the server with the SSL certificate embedded that is associated with particular logged in OpenID user. After that, j2me client could authenticate to the server without entering any username/password. The data that is going to be stored on the server is not THAT sensitive - considering cases of mobile phone thefts etc.
Can anybody come up with a better solution?
The best solution IMO for what you're doing is to use OAuth combined with OpenID. You're use of OpenID at the RP is fine. But for installed applications that need access to that web site, they should use OAuth to get authorized. The flow would work like this:
User installs app on their device
During install or on first launch, the app has an "Authorize me" button.
The user presses the button and a web browser pops up the web site that the client app needs to access data from.
User logs into that site using their OpenID
Site now asks "do you want to authorize client app X?"
User says yes and closes the browser.
The client app reappears and says "thanks." and now has the OAuth token necessary to access the user's data without the user ever logging in again.