The Blazorade.Id.Configuration.AuthorityOptions class is defined in the Blazorade.Id.Core assembly.

You use this class to configure different options for Blazorade ID. The properties that you can set on this class are described below.

Specifies the client ID of your application. This is provided by your IdP. Blazorade ID cannot communicate with the IdP without this information.

This is the URI to the OpenID Discovery Document for your IdP. The OpenID specification requires that all OpenID / OAuth compliant Identity Providers (IdP) publish a discovery document that is located at a predictable location.

For Microsoft Entra ID, the discovery document is located at:

https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration

For Microsoft Entra External ID, the discovery document is located at:

https://{tenant-name}.ciamlogin.com/{tenant-id}/v2.0/.well-known/openid-configuration

Here, {tenant-id} is either the ID (Guid) that represents the tenant, the default domain for the tenant, or any additional domain you have registered with the tenant. {tenant-name} is the first part of the default domain for the tenant. So, for instance in mycompany.onmicrosoft.com, mycompany is the tenant name.

Defines the default scopes that you application will use, in case you acquire tokens without specifying scopes. The default value for this property is: openid profile email

Whenever you call the ITokenService.GetAccessTokensAsync() or ITokenService.GetIdentityTokenAsync() and do not explicitly specify the scopes you want to be included in the tokens, the scopes defined here are used.

With Blazorade ID you can request any scopes at runtime when your application needs them. You don't have to specify all the scopes your application might use up-front. That is one of the design principles in Blazorade ID

However, it is still a good idea to specify a basic set of scopes in the configuration for your application. Think of them as a minimal set of scopes that your application can't work without. Try to stick to scopes that do not required admin consent, because that would mean that users who are not allowed to do admin consent cannot use your application at all.

Request scopes that require admin consent in your application when the application needs them.

If you don't specify the DocumentDiscoveryUri property, you must configure the authorization endpoint to your IdP. You do that with the AuthorizationEndpoint property.

It is highly recommended to use the DocumentDiscoveryUri property, since that includes all endpoint URIs that Blazorade ID requires.

If you don't specify the DocumentDiscoveryUri property, you must configure the token endpoint to your IdP. You do that with the TokenEndpoint property.

It is highly recommended to use the DocumentDiscoveryUri property, since that includes all endpoint URIs that Blazorade ID requires.

If you don't specify the DocumentDiscoveryUri property, you may configure the end session endpoint to your IdP. You do that with the EndSessionEndpoint property.

The EndSessionEndpoint is optional. If Blazorade ID cannot figure out the end session endpoint, either from this property or thought the DocumentDiscoveryUri, then signing out does not end the user's session with the IdP. It only clears the tokens stored by Blazorade ID.

The URL you want your IdP to redirect your users back to you application after authentication.

This property is optional. If you don't specify it, Blazorade ID will handle the callback from your IdP automatically, as long as you have configured Blazorade.Id as an additional assembly in your routing as described in the getting started section.

If you need to customize the redirect URI for some reason, you can create your own callback page pretty easily with the help of the OAuthCallbackHandler component that Blazorade ID provides.

Enables a silent, non-interactive OAuth 2.0 Authorization Code Flow with PKCE to acquire tokens without user-visible prompts.

When enabled, the configured IAuthorizationCodeProvider implementation may decide to attempt authorization without direct user interaction, typically by reusing an existing authenticated browser session with the identity provider. Whether and when a silent authorization attempt is performed is determined by the provider implementation.

If this is disabled, the configured IAuthorizationCodeProvider must not attempt silent authorization code flow.

Silent authorization is a best-effort optimization and is subject to browser privacy restrictions, identity provider behavior, and user session state. This option does not use refresh tokens and does not guarantee success. If silent authorization is not possible, the provider will fall back to an interactive authorization flow.

This option is false by default.