The OpenID Connect (OIDC) protocol for Microsoft Azure uses the [Microsoft identity platform (v2) endpoints](https://docs.microsoft.com/en-us/azure/active-directory/azuread-dev/azure-ad-endpoint-comparison).
To get started, sign in to the [Azure Portal](https://portal.azure.com). For your app, you'll need the
To get started, sign in to the [Azure Portal](https://portal.azure.com). For your app, you need the
following information:
- A tenant ID. You may already have one. For more information, review the
See the [token compatibility settings](https://docs.microsoft.com/en-us/azure/active-directory-b2c/configure-tokens?pivots=b2c-custom-policy#token-compatibility-settings).
In `TrustFrameworkBase.xml` under `JwtIssuer`, set `IssuanceClaimPattern` to `AuthorityWithTfp`:
See the [token compatibility settings](https://docs.microsoft.com/en-us/azure/active-directory-b2c/configure-tokens?pivots=b2c-custom-policy#token-compatibility-settings).
In `TrustFrameworkBase.xml` under `JwtIssuer`, set `IssuanceClaimPattern` to `AuthorityWithTfp`:
1. Now [upload the policy](https://docs.microsoft.com/en-us/azure/active-directory-b2c/tutorial-create-user-flows?pivots=b2c-custom-policy#upload-the-policies). Overwrite
the existing files if you are updating an existing policy.
the existing files if you are updating an existing policy.
1. Determine the issuer URL using the sign-in policy. The issuer URL will be in the form:
1. Determine the issuer URL using the sign-in policy. The issuer URL is in the form:
- Ensure all occurrences of `yourtenant.onmicrosoft.com`, `ProxyIdentityExperienceFrameworkAppId`, and `IdentityExperienceFrameworkAppId` match your B2C tenant hostname and
the respective client IDs in the XML policy files.
the respective client IDs in the XML policy files.
- Add `https://jwt.ms` as a redirect URI to the app, and use the [custom policy tester](https://docs.microsoft.com/en-us/azure/active-directory-b2c/tutorial-create-user-flows?pivots=b2c-custom-policy#test-the-custom-policy).
Make sure the payload includes `email` that matches the user's email access.
Make sure the payload includes `email` that matches the user's email access.
- After you enable the custom policy, users might see "Invalid username or password" after they try to sign in. This might be a configuration
issue with the `IdentityExperienceFramework` app. See [this Microsoft comment](https://docs.microsoft.com/en-us/answers/questions/50355/unable-to-sign-on-using-custom-policy.html?childToView=122370#comment-122370)
that suggests checking that the app manifest contains these settings:
issue with the `IdentityExperienceFramework` app. See [this Microsoft comment](https://docs.microsoft.com/en-us/answers/questions/50355/unable-to-sign-on-using-custom-policy.html?childToView=122370#comment-122370)
that suggests checking that the app manifest contains these settings:
-`"accessTokenAcceptedVersion": null`
-`"signInAudience": "AzureADMyOrg"`
Note that this configuration corresponds with the `Supported account types` setting used when creating the `IdentityExperienceFramework` app.
Note that this configuration corresponds with the `Supported account types` setting used when
creating the `IdentityExperienceFramework` app.
#### Keycloak
...
...
@@ -347,10 +345,9 @@ GitLab works with OpenID providers that use HTTPS. Although a Keycloak
server can be set up using HTTP, GitLab can only communicate
with a Keycloak server that uses HTTPS.
We highly recommend configuring Keycloak to use public key encryption
algorithms (for example, RSA256, RSA512, and so on) instead of symmetric key
encryption algorithms (for example, HS256 or HS358) to sign tokens. Public key
encryption algorithms are:
We highly recommend configuring Keycloak to use public key encryption algorithms (for example,
RSA256, RSA512, and so on) instead of symmetric key encryption algorithms (for example, HS256 or HS358) to
sign tokens. Public key encryption algorithms are:
- Easier to configure.
- More secure because leaking the private key has severe security consequences.
...
...
@@ -393,78 +390,73 @@ encryption should only be used when absolutely necessary.
To use symmetric key encryption:
1. Extract the secret key from the Keycloak database. Keycloak doesn't
expose this value in the Web interface. The client secret seen in the
Web interface is the OAuth2 client secret, which is different from the
secret used to sign JSON Web Tokens.
For example, if you're using PostgreSQL as the backend database for
Keycloak, login to the database console and extract the key via this SQL
query:
```sql
$ psql -U keycloak
psql (13.3 (Debian 13.3-1.pgdg100+1))
Type "help" for help.
keycloak=# SELECT c.name, value FROM component_config CC INNER JOIN component C ON(CC.component_id = C.id) WHERE C.realm_id = 'master' and provider_id = 'hmac-generated' AND CC.name = 'secret';
-[ RECORD 1 ]---------------------------------------------------------------------------------
name | hmac-generated
value | lo6cqjD6Ika8pk7qc3fpFx9ysrhf7E62-sqGc8drp3XW-wr93zru8PFsQokHZZuJJbaUXvmiOftCZM3C4KW3-g
-[ RECORD 2 ]---------------------------------------------------------------------------------
name | fallback-HS384
value | UfVqmIs--U61UYsRH-NYBH3_mlluLONpg_zN7CXEwkJcO9xdRNlzZfmfDLPtf2xSTMvqu08R2VhLr-8G-oZ47A
```
In this example, there are two private keys: one for HS256
(`hmac-generated`), and another for HS384 (`fallback-HS384`). We'll use
the first `value` to configure GitLab.
1. Convert `value` to standard base64. As [discussed in the
