Is it possible to use Auth0 Authorization Code Flow without Auth0 lock (widget)?
Auth0 /authorize endpoint always redirects to auth0 lock, can it redirect to custom login page?
Short Answer: Auth0 is not suitable for custom login page.
Long Answer:
The only solution provided by Auth0 is embedded login for web, but it has security issues and hard to setup. Quoting from their website:
There are security concerns with this approach, particularly if you do not use the Custom Domains feature at Auth0, as this potentially opens your application up to cross-origin authentication issues.
In fact, Chrome is going to disable cross-origin authentication attempts in the future:
https://www.chromium.org/Home/chromium-security/extension-content-script-fetches/
Quoting Again from Chromium > Chromium Security >
Changes to Cross-Origin Requests in Chrome Extension Content Scripts
tl;dr: To improve security, cross-origin fetches will soon be disallowed from content scripts in Chrome Extensions. Such requests can be made from extension background pages instead, and relayed to content scripts when needed.
Related
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?
I have to use Auth0 for the application and need to bypass Spartacus password login flow. I have gone through https://sap.github.io/spartacus-docs/session-management/#configuring-authorization-code-flow-or implicit-flow found that there is implicit flow to bypass login.
Tried with "authorizationserver/oauth/token" API hit manually and store token in local storage but getting other issues.
Can I know better approach to implement Auth0 in Spartacus and bypass password login flow.
Spartacus supports 3 flows with OAuth without any serious modifications required.
Password flow -> the default one. You login in spartacus form and the credentials are send to server and exchanged for access_token.
Implicit flow -> When you click login you are redirected to OAuth server login page. You put credentials there and after that you get redirected back to spartacus with access_token in on of the query params of the redirect url.
Authorization Code flow -> similar to Implicit flow, but in response you get code which then you need to send to oAuth server to exchange it for access_token.
To specify which flow you want to use you need to change the responseType config as mentioned in https://sap.github.io/spartacus-docs/session-management/#configuring-authorization-code-flow-or-implicit-flow
For Auth0 I would recommend going with Authorization Code Flow (as it's more secure than Implicit flow, especially with PKCE enabled).
Apart from the responseType you would need to set baseUrl in auth config to point it to Auth0 server (and I assume you have integration done in the backend that can verify tokens returned from Auth0). You might need to adjust few other config options as well, but you should be able to figure those out based on the problems you encounter.
I need to change CSP in response that contains login page from IdentityServer4 in order to render that page in iframe in my client app. Is it possible?
Here you can find a sample MVC application where we have implemented a login mechanism to an IdentityServer4 instance using the authorization code flow but using an iframe. The flow is not that different from redirecting to the authority. Using an iframe just hides the redirection from the user which some believe provides a better user experience.
Regarding IdentityServer4 you need to add the this directive to the CSP. Also it would be good to configure your IS4 not to display a logout prompt, so you can have a seamless logout experience.
The authorize endpoint will already allow this but the login page is under your control so it should be just a matter of setting the CSP header yourself via an MVC filter or similar.
Be aware though that if you use federation to other providers it will likely not work as their CSP will almost certainly not allow your origin as a frame-ancestor.
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'm trying to implement Firebase's Google authentication in the popup window of a chrome extension. The regular email/password authentication works fine, but when I try with Google auth, it hangs on a grey screen whose URL begins with "https://auth.firebase.com/auth/google/callback?state=..."
Any idea what the issue is?
Note that Firebase Simple Login is a separate service built on top of Firebase Authentication, intended to simplify authenticating users and generating Firebase Auth. Tokens for use in Security Rules.
At the time of this writing, authenticating via pop-up in a browser extension is unsupported via Firebase Simple Login, due to the constraints around authenticating origins in OAuth. In order to use Firebase Simple Login for this task, the login will have to take place on a hosted domain.
See Firebase Authentication in a Chrome Extension Background Page for related information and answer.