Following up on my original post on forum:
How to get delegation token using lock (Angular 1.x)
I followed the tutorials & managed to set it up. However I am confused now.
When calling the /authorise url , Auth0 displays the login (lock) screen to the user.
This implementation of implicit grant in Auth0 is weird & not as per the OAuth 2 standard.
Implicit grant is supposed to happen after the user is authenticated, it is not used to authenticate the user.
Here is the scenario I want to have:
-
Angular SPA displays the login screen to the user. User inputs the credentials. SPA authenticates the user using the credentials.
-
Once authenticated, the SPA gets the “access__token” in order to make calls to ASP.net WebAPI (resource server)
Can this be achieved using Auth0?
Hi @eatfitdev,
Can you please describe the inconsistencies you see between the Auth0 implementation, and the OAuth spec? The implicit grant flow achieves the requirements of your scenario, where:
- User will be authenticated
- Your SPA will receive an
access_token
directly, without intermediate credentials (authorization code) required.
As per the OAuth 2.0 spec:
In the implicit flow, instead of
issuing the client an authorization
code, the client is issued an access
token directly (as the result of the
resource owner authorization).
The login is required to perform the resource owner authorization. Let me know if I have misunderstood something.
Thanks for your reply @prashant .
The reason I find it different is because, if the user isn’t logged in , the “/authorize” url displays a login prompt.
This login dialog is for resource owner credentials but there is no configuration for Auth0 to use the application login for this. It uses the hosted pages instead.
I found the “prompt=none” setting which can get rid of login prompt I was getting.
However, the ASP.net Web API, cannot authorize the “access_token” I receive from the implicit grant flow.
The quick start sample mentioned in the API, has the configuration for ASP.net Core & not ASP.net standard.
var options = new JwtBearerOptions
{
Audience = "https://example.resourceserver.io",
Authority = "https://example.eu.auth0.com/"
};
app.UseJwtBearerAuthentication(options);
app.UseMvc();
Is there a sample which describes the startup.cs configuration to be made in ASP.net Web API which enables it to authorize implicit grant access tokens?
I was following the tutorial here : Auth0 ASP.NET Web API (OWIN) SDK Quickstarts: Authorization
public void Configuration(IAppBuilder app)
{
var issuer = $"https://{ConfigurationManager.AppSettings"Auth0Domain"]}/";
var audience = ConfigurationManager.AppSettings"Auth0ClientID"];
// Api controllers with an [Authorize] attribute will be validated with JWT
app.UseActiveDirectoryFederationServicesBearerAuthentication(
new ActiveDirectoryFederationServicesBearerAuthenticationOptions
{
TokenValidationParameters = new TokenValidationParameters
{
ValidAudience = audience,
ValidIssuer = issuer,
IssuerSigningKeyResolver = (token, securityToken, identifier, parameters) => parameters.IssuerSigningTokens.FirstOrDefault()?.SecurityKeys?.FirstOrDefault()
},
// Setting the MetadataEndpoint so the middleware can download the RS256 certificate
MetadataEndpoint = $"{issuer.TrimEnd('/')}/wsfed/{audience}/FederationMetadata/2007-06/FederationMetadata.xml"
});
// Configure Web API
WebApiConfig.Configure(app);
}
This doesn’t authorize the “access_token” received from implicit grant flow either.
I found the web API configuration from here :
This configuration for startup works!
var domain = $"https://{ConfigurationManager.AppSettings"Auth0Domain"]}/";
var apiIdentifier = ConfigurationManager.AppSettings"Auth0ApiIdentifier"];
var keyResolver = new OpenIdConnectSigningKeyResolver(domain);
app.UseJwtBearerAuthentication(
new JwtBearerAuthenticationOptions
{
AuthenticationMode = AuthenticationMode.Active,
TokenValidationParameters = new TokenValidationParameters()
{
ValidAudience = apiIdentifier,
ValidIssuer = domain,
IssuerSigningKeyResolver = (token, securityToken, identifier, parameters) => keyResolver.GetSigningKey(identifier)
}
});