@@ -118,9 +118,9 @@ The following secret validators are part of Duende IdentityServer:
118
118
119
119
## Shared Secrets
120
120
121
- Shared secrets is by far the most common technique for authenticating clients.
121
+ Using shared secrets is by far the most common technique for authenticating clients.
122
122
123
- From a security point of view they have some shortcomings
123
+ From a security point of view, they have some shortcomings:
124
124
125
125
* the shared secrets must be transmitted over the network during authentication
126
126
* they should not be persisted in clear text to reduce the risk of leaking them
@@ -152,7 +152,7 @@ var compromisedSecret = new Secret("just for demos, not prod!".Sha256());
152
152
153
153
### Authentication Using A Shared Secret
154
154
155
- You can either send the client id/secret combination as part of the POST body::
155
+ You can either send the client id/secret combination as part of the POST body:
156
156
157
157
``` http request
158
158
POST /connect/token
@@ -167,7 +167,7 @@ Content-type: application/x-www-form-urlencoded
167
167
redirect_uri=https://myapp.com/callback
168
168
```
169
169
170
- ...or as a basic authentication header::
170
+ ...or as a basic authentication header:
171
171
172
172
``` http request
173
173
POST /connect/token
@@ -209,7 +209,7 @@ The OpenID Connect specification recommends a client authentication method based
209
209
instead of transmitting the shared secret over the network, the client creates a JWT and signs it with its private key.
210
210
Your IdentityServer only needs to store the corresponding key to be able to validate the signature.
211
211
212
- The technique is described [ here] ( https://openid.net/specs/openid-connect-core-1_0.html#clientauthentication ) and is
212
+ The technique is described [ here] ( https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication ) and is
213
213
based on the OAuth JWT assertion specification [ (RFC 7523)] ( https://tools.ietf.org/html/rfc7523 ) .
214
214
215
215
### Setting Up A Private Key JWT Secret
@@ -230,7 +230,7 @@ var client = new Client
230
230
Type = IdentityServerConstants .SecretTypes .X509CertificateBase64 ,
231
231
232
232
Value = " MIID...xBXQ="
233
- }
233
+ },
234
234
new Secret
235
235
{
236
236
// JWK formatted RSA key
@@ -327,15 +327,14 @@ static async Task<TokenResponse> RequestTokenAsync(SigningCredentials credential
327
327
}
328
328
```
329
329
330
- See [ here] ( /identityserver/samples/basics#jwt-based-client-authentication ) for a sample for using JWT-based
331
- authentication.
330
+ See [ here] ( /identityserver/samples/basics#jwt-based-client-authentication ) for a sample for using JWT-based authentication.
332
331
333
332
### Using ASP.NET Core
334
333
335
334
The OpenID Connect authentication handler in ASP.NET Core allows for replacing a static client secret with a dynamically
336
335
created client assertion.
337
336
338
- This is accomplished by handling the various events on the handler. We recommend to encapsulate the event handler in a
337
+ You can achieve this by handling the various events on the handler. We recommend encapsulating the event handler in a
339
338
separate type. This makes it easier to consume services from DI:
340
339
341
340
``` csharp
@@ -384,7 +383,7 @@ JWT-based authentication (and signed authorize requests) in ASP.NET Core.
384
383
385
384
## Strict Audience Validation
386
385
387
- Private key JWT have a theoretical vulnerability where a Relying Party trusting multiple
386
+ Private key JWTs have a theoretical vulnerability where a Relying Party trusting multiple
388
387
OpenID Providers could be attacked if one of the OpenID Providers is malicious or compromised.
389
388
390
389
The attack relies on the OpenID Provider setting the audience value of the authentication JWT
0 commit comments