Simplify boilerplate configuration for web and api applicaitons

[bdemers]

Describe the feature request?

The default configuration needed to initialize an API (or web) application can be reduced/simplified for basic use cases.

• OktaWebApiOptions should allow the caller to set the Issuer instead of requiring both the OktaDomain and the AuthorizationServerId (this could be done backward compatible and not affect existing users).

NOTE: Okta's API quick start guides will be using the Issuer instead of the Okta Domain.

• Configuration parameters should be parsed from known configuration keys Okta:OktaDomain, Okta:AuthorizationServerId, Okta:Issuer, etç. automatically when possible.

• Consider adding a util method to configure the AuthenticationOptions as a single line.

For example, the current quick start looks similar to this:

services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultSignInScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddOktaWebApi(new OktaWebApiOptions(Configuration)
{
    OktaDomain = Configuration["Okta:OktaDomain"]
});

services.AddAuthorization();

This requires the developer to understand a number of things to configure the framework correctly.

Ideally, we could do something like:

services.AddAuthentication(options =>
{
    Okta.AddAuthentication(options); // some sort of helper method
})
.AddOktaWebApi(new OktaWebApiOptions(Configuration)); // add a `OktaWebApiOptions` constructor to parse the config

services.AddAuthorization();

If possible... we could reduce this even further to something like:

public void ConfigureServices(IServiceCollection services)
{
    Okta.ConfigureApiServices(services, new OktaWebApiOptions(Configuration));
}

This last option may make it too "magical" and more difficult to figure out the touchpoints when a developer needs to configure other authentication/authorization options?

NOTE: Take this all with a grain of salt 🧂, as I'm not sure what the equivalent idiomatic csharp would be.

.NET Version

💯

Provide a documentation link if applicable

No response

Additional Information?

No response

[monde]

Thanks @bdemers

[agilenut]

I like the idea to support binding to a single Issuer URL in addition to the OktaDomain and AuthorizationServerId. I also like the idea to support a default configuration section name.

As mentioned in the PR, #184 mentions other concerns with configuration which is that, not only does it not support configuration binding, but it does not support configuration reload.

Also, we should be careful about how we implement the default section name. Consumers should be able to use their own section config names if desired and use Configuration.GetSection("MyOktaSectionName") to pass in the okta section. It's fine if you want to use "Okta" as the default but not at the expense of allowing consumers to structure their config as they would like.