Registo de aplicação OpenID Connect

O registo de aplicação OpenID Connect do FoxIDs permite-lhe ligar uma aplicação baseada em OpenID Connect.

FoxIDs OpenID Connect application registration

A sua aplicação torna-se uma Relying Party (RP) e o FoxIDs atua como OpenID Provider (OP).

O FoxIDs suporta OpenID Connect discovery, pelo que a sua aplicação pode descobrir o OpenID Provider.

O FoxIDs suporta autenticação OpenID Connect, RP-initiated logout e front-channel logout. É estabelecida uma sessão quando o utilizador se autentica e o session ID é incluído no ID token. A sessão é invalidada no logout.

O FoxIDs pode mostrar uma janela de confirmação de logout dependendo da configuração do cliente e de um pedido de logout incluir ou não um ID token.

Por predefinição, tanto o ID token como o access token usam o client ID como audience. O recurso predefinido pode ser removido do access token no FoxIDs Control.

Os access tokens também podem ser emitidos com várias audiences e, por isso, direcionar várias APIs definidas no FoxIDs como recursos OAuth 2.0. A aplicação pode depois chamar uma API e proteger o pedido com o access token.

O FoxIDs suporta tanto client secret como Proof Key for Code Exchange (PKCE), e o PKCE está ativado por predefinição. Se um cliente estiver configurado tanto com PKCE como com secret ou chave, ambos são validados. PKCE e client secret ou chave não são validados no fluxo implícito.

O método de autenticação do cliente predefinido é client secret post e pode ser alterado para client secret basic ou private key JWT. O método de autenticação do cliente none é suportado com PKCE.

Podem ser configurados até 10 secrets e 4 chaves por cliente.

O FoxIDs suporta o endpoint OpenID Connect UserInfo.

Guias práticos:

Ligar Tailscale

Ligar ambientes FoxIDs

Os ambientes FoxIDs podem ser ligados de duas formas:

Environment Link para ambientes no mesmo tenant.
OpenID Connect para ambientes no mesmo tenant ou em tenants diferentes.

Escolha Environment Link quando ambos os ambientes estiverem no mesmo tenant e quiser a configuração mais simples. Escolha OpenID Connect quando precisar de ligar tenants diferentes ou implementações FoxIDs separadas.

Exigir autenticação multifator (MFA)

O cliente OpenID Connect pode exigir MFA incluindo urn:foxids:mfa no parâmetro acr_values. Pode combiná-lo com valores mais específicos, como urn:foxids:link. Consulte pedir MFA a partir das aplicações.

O parâmetro acr_values pode ser definido no evento OnRedirectToIdentityProvider em Startup.cs:

options.Events.OnRedirectToIdentityProvider = (context) =>
{
    // To require MFA
    context.ProtocolMessage.AcrValues = "urn:foxids:mfa";
    return Task.FromResult(string.Empty);
};

Veja mais código em AspNetCoreOidcAuthorizationCodeSample e Startup.cs line 141.

Configuração

Como configurar a sua aplicação como registo de aplicação OpenID Connect, Relying Party (RP) ou cliente.

O documento discovery do cliente FoxIDs é https://foxids.com/tenant-x/environment-y/application-client1/.well-known/openid-configuration se o cliente estiver configurado no tenant tenant-x, ambiente environment-y, com o nome de cliente de registo de aplicação application-client1.

Um cliente de registo de aplicação pode suportar login via vários métodos de autenticação adicionando o nome do método de autenticação ao URL. Por exemplo, um nome de método de autenticação como login pode ser adicionado ao URL discovery assim: https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration

Durante RP-initiated logout, o nome do método de autenticação pode ser omitido do URL se o ID token for fornecido no pedido.

Configurar Authorization Code Flow para um cliente confidencial

Um cliente confidencial é tipicamente uma aplicação web server-side em que o servidor web guarda o client secret.

Especifique o nome do cliente no nome do registo de aplicação.
Selecione os métodos de autenticação permitidos.
Especifique os URIs de redirect.
Especifique o URI de redirect pós-logout.
Selecione code como response type ou, opcionalmente mas não recomendado, code token ou code token id_token.
PKCE não é necessário para um cliente confidencial, mas é recomendado para mitigar ataques de replay.
Especifique um secret.

Configure Authorization Code Flow

Configurar Authorization Code Flow para um cliente público

Um cliente público pode ser um rich client baseado em browser, um cliente Blazor ou uma app mobile. A aplicação deve usar PKCE e não deve usar client secret.

Especifique o nome do cliente no nome do registo de aplicação.
Selecione os métodos de autenticação permitidos.
Especifique os URIs de redirect.
Especifique o URI de redirect pós-logout.
Selecione code como response type.
Use PKCE, que está ativado por predefinição.

Clique em Show advanced para configurar as CORS origins permitidas.

Configure Authorization Code Flow with PKCE

Configurar Implicit Code Flow para um cliente público

Um cliente público pode ser um rich client baseado em browser. A aplicação não usa PKCE nem client secret.

Não é recomendado usar Implicit Code Flow porque é inseguro.

Especifique o nome do cliente no nome do registo de aplicação.
Selecione os métodos de autenticação permitidos.
Especifique os URIs de redirect.
Especifique o URI de redirect pós-logout.
Selecione token id_token como response type ou, opcionalmente, apenas token.
Desative PKCE.
Não especifique um secret.

Configure Implicit Code Flow

Cliente e API

É possível configurar tanto o cliente como a API, que é um recurso OAuth 2.0, no mesmo registo de aplicação OpenID Connect. Nesse caso, tanto o cliente como a API são definidos com o mesmo nome. Também pode configurar resource scopes para a API.

Client tab

Configure Client and API - Client

Resource tab

Configure Client and API - Resource

Resource and Scopes

Uma API é definida como recurso e os scopes são definidos nesse recurso. Esses scopes usam o formato nome do recurso ponto scope, por exemplo application-api1.read1 ou application-api1.read2.

No separador de configuração do cliente, os scopes são definidos abaixo do campo nome do recurso.

Resource and scopes - Client

No separador de configuração do recurso, os scopes são definidos como uma lista de valores de scope.

Resource and scopes - Resource

Os scopes configurados no cliente são validados em relação aos scopes existentes na API. Se cliente e API estiverem configurados no mesmo registo de aplicação, os scopes adicionados ao cliente são automaticamente adicionados ao recurso.

Scope

Os scopes podem ser configurados no separador de configuração do cliente. Pode definir novos scopes e o conjunto de claims que devem ser emitidos para esses scopes na lista Voluntary claims.

Pode modificar claims e implementar claim tasks com transformações e tarefas de claims.

Se estiver a criar um novo claim, adicione o claim ou * à lista Issue claims, ou adicione o claim à lista Voluntary claims e peça o scope a partir da sua aplicação.

É adicionado à configuração do cliente um conjunto de scopes predefinidos que depois pode ser alterado ou eliminado.

Default scopes

Lifetime de tokens

O lifetime do token é configurado para ID token, access token e refresh token.

Token lifetime

Neste exemplo, cada refresh token é válido por 36.000 segundos. A aplicação pode continuar a renovar a sessão com refresh tokens até ser atingido o lifetime absoluto de 86.400 segundos.