Is using checkSession compatible with SAML type redirect flows? With renewAuth, I used to be able to pass redirectUri and usePostMessage to do silent auth callback. But does not seem to be working with checkSession. I'm using the latest auth0.js.
checkSession itself uses OIDC/OAuth2 (as do all the authentication-related features of Auth0.js). But that's the protocol between the application and Auth0.
The upstream connection can use any of the available protocols (including SAML) because in the checkSession flow Auth0 will not go to the upstream identity provider, relying instead on the Auth0 session.
If this is not working, might be work looking into other reasons. Check the console for errors, as well as the actual HTTP response from Auth0.
Related
I want to develop an authentication mechanism for 3rd party applications using keycloak initial access tokens. But I want to do this only by using the access tokens that I have generated in the keycloak. For example, I will give a generated token to the user and allow him to log into the application. Is this possible? How can i do that?
Initial Access Token
First, I'm not sure it is a good idea to use "initial access token" for authorizing requests to your own resources. It might even not be allowed. As per the doc:
An initial access token can only be used to create clients
Second, don't use keycloak libs for Spring as suggested in other answer. It is very deprecated.
Last, a REST API secured with Oauth2 is a resource-server (and not a client). As so, the dependency should be spring-boot-starter-oauth2-resource-server. Spring doc is pretty extensive on the subject. You can also have a look at those tutorials for resource-server configuration (and OAuth2 definitions).
Once the resource-server (Spring REST API) is configured, clients will have to authorize their requests as normal for OAuth2: provide with an Authorization header containing a Bearer access-token (a JWT issued by Keycloak to the client with one of standard flows: client-credentials or authorization-code depending you need to authorize the client itself or a user behind it).
Edit
I might have misunderstood your need. If what you want is having new clients register themself programmatically on your Keycloak instance, then those clients will just issue a REST request to Keycloak server API with the "initial access token" in Authorization header as normal.
Once registered, those clients will be able to call you resource-servers as described in my initial answer.
Note that I'm quite new with OAuth2 and OpenID Connect so I may be a little bit confused. AFAIK, the recommanded authentication flow with OAuth2 in 2021 is Authorization Code Flow. I have already read the RFC 6749.
I have initialized a project using JHipster (v6.10.5, not the v7) with this configuration:
Which type of application would you like to create? Monolithic application (recommended for simple projects)
Which type of authentication would you like to use? OAuth 2.0 / OIDC Authentication (stateful, works with Keycloak and Okta)
Which Framework would you like to use for the client? React (i.e. a SPA application)
I'm wondering why is the JHipster's implementation stateful? (i.e. using HTTP session cookie JSESSIONID ; access token and refresh token are stored on the backend-side and NOT on the browser-side).
Why don't they make the browser acting as an OAuth 2.0 client to perform the authentication and storing the access token and the refresh token on the browser-side?
I don't find any explanation on the JHispter security page.
Beside, this blog mentions a schema that explains the OIDC Authorization Code Flow with a Public Client / SPA.
To complete Matt Raible comment, from OAuth 2.0 for Browser-Based Apps - draft-ietf-oauth-browser-based-apps-07 and ยง6.1. Browser-Based Apps that Can Share Data with the Resource Server:
[...]
An additional concern with handling access tokens in a browser is that as of the date of this publication, there is no secure storage mechanism where JavaScript code can keep the access token to be later used in an API request. Using an OAuth flow results in the JavaScript code getting an access token, needing to store it somewhere, and then retrieve it to make an API request.
Instead, a more secure design is to use an HTTP-only cookie between the JavaScript application and API so that the JavaScript code can't access the cookie value itself. Additionally, the SameSite cookie attribute can be used to prevent CSRF attacks, or alternatively, the application and API could be written to use anti-CSRF tokens.
[...]
However, I think the use of HTTP-session and OAuth2 token on the backend-side may complexify the management/implementation of some issues as we have to handle different timeouts:
idle timeout for HTTP session between the browser and the backend
expiration timeout or maximum lifetime expiration for the refresh token that is stored on the backend side
...
I'm now wondering how to provide a user-friendly experience, when some borderline cases happen. E.g: when the refresh token has expired on the backend-side but the end-user is still connected as the HTTP session between the browser and the backend is still valid.
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.
According to https://dev.twitter.com/docs/api/1/post/oauth/request_token, it is strongly recommended you use HTTPS for all OAuth authorization steps. However, I found out the callback url is not following this suggestion. Is there a difference if a https callback url is given vs a http callback url is given?
For example,
Request URL:
POST https://api.twitter.com/oauth/request_token
Authorization Header:
oauth_callback="http%3A%2F%2Fmyapp.com%3A3005%2Ftwitter%2Fprocess_callback",
The callback URL just needs to in a url format, the Oauth spec does not mandate that it is https.
Certain Oauth providers (like SalesForce) do force the use of https.
Most service providers however just force you to register you callback url so that the service provider can verify that the correct callback url is provided during an oauth dance using your consumer key / secret.
Also, mobile apps in Android can create special protocol handlers, allowing callback handlers like "linkedin://callback" to be defined (to let the Android app handle linkedin oauth callbacks).
In that scenario it wouldn't make sense to force https, as it would force mobile apps to off-load their oauth dance to a remote server, where in some cases its perfectly acceptable to do it in the app itself.
Also keep in mind that whe the access token is compromised, people wishing to make secured api calls also need access to the consumer key / consumer secret.
I have been looking at the Thinktecture.IdentityModel.40 library as a way of handling the security of my Asp.Net WebApi. One point I don't understand is the following, and this is my question.
When the user authenticates the first time, they need to supply their username and password. If they are authenticated, they are issued a token to use for all the other calls.
Using the above library, I use the method, AddBasicAuthentication to the security config.
Will this by default use the token issuing mechanism, or do I need to use the AddSimpleWebToken?
And If so, how do I tie the two mechanisms together?
There is no token issuance yet. I am working on that feature.