You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/pages/verify/integrations/aspnet-core-v6.mdx
+17-17Lines changed: 17 additions & 17 deletions
Original file line number
Diff line number
Diff line change
@@ -9,23 +9,23 @@ subtitle: Accept MitID, Swedish BankID, Norwegian BankID and other eID logins wi
9
9
This tutorial demonstrates how to integrate Criipto Verify into a fresh ASP.NET Core 6.0 application created with `dotnet new mvc`.
10
10
The principles should apply to any ASP.NET Core 6.0 application.
11
11
12
-
You can download a [sample application from GitHub](https://github.com/criipto/samples/tree/master/Verify/dotnet-core-v6.x)
12
+
You can download a [sample application from GitHub](https://github.com/criipto/samples/tree/master/Verify/dotnet-core-v6.x).
13
13
14
14
## Register Your Application in Criipto Verify
15
15
16
16
After you signed up for Criipto Verify, you must [register an application](https://dashboard.criipto.com/applications/add) before you can actually try logging in with any eID.
17
17
18
-
Once you register your application you will also need some of the information for communicating with Criipto Verify. You get these details from the settings of the application in the dashboard.
18
+
Once you register your application, you will also need some of the information for communicating with Criipto Verify. You get these details from the application settings in the dashboard.
19
19
20
20
Specifically you need the following information to configure you application
21
21
22
22
-_Client ID_ to identify you application to Criipto Verify.
23
-
-_Domain_ on which you will be communicating with Criipto Verify.
23
+
-_[Domain](/verify/getting-started/basics/#domains)_ on which you will be communicating with Criipto Verify.
24
24
-_Client Secret_ to perform code exchange.
25
25
26
26
### Register callback URLs
27
27
28
-
Before you can start sending authentication requests to Criipto Verify you need to register the URLs on which you want to receive the returned *JSON Web Token*, JWT.
28
+
Before you can start sending authentication requests to Criipto Verify, you need to register the URLs on which you want to receive the returned *JSON Web Token*, JWT.
29
29
30
30
The Callback URL of your application is the URL where Criipto Verify will redirect to after the user has authenticated in order for the OpenID Connect ASP.NET middleware to complete the authentication process.
31
31
@@ -38,9 +38,9 @@ https://localhost:5001/signout
38
38
http://localhost:5000/signout
39
39
```
40
40
41
-
If you deploy your application to a different URL you will also need to ensure to add that URL to the Callback URLs.
41
+
If you deploy your application to a different URL, you will need to add that URL to the Callback URLs as well.
You can have a look at our [sample Program.cs](https://github.com/criipto/samples/blob/master/Verify/dotnet-core-v6.x/Program.cs) to see how it fits together with the rest of Program.cs
105
+
You can have a look at our [sample Program.cs](https://github.com/criipto/samples/blob/master/Verify/dotnet-core-v6.x/Program.cs) to see how it fits together with the rest of `Program.cs`.
106
106
107
107
### Enable the OpenID Connect middleware
108
108
@@ -116,7 +116,7 @@ app.UseAuthorization();
116
116
117
117
```
118
118
119
-
You can have a look at our [sample Program.cs](https://github.com/criipto/samples/blob/master/Verify/dotnet-core-v6.x/Program.cs) to see how it fits together with the rest of Program.cs
119
+
You can have a look at our [sample Program.cs](https://github.com/criipto/samples/blob/master/Verify/dotnet-core-v6.x/Program.cs) to see how it fits together with the rest of `Program.cs`.
120
120
121
121
## Trigger Login and Logout in Your Application
122
122
@@ -153,19 +153,19 @@ public async Task Logout()
153
153
154
154
## The runtime flow
155
155
156
-
In summary, the steps above will lead to a runtime flow looks like this:
156
+
In summary, the steps above will lead to a runtime flow that looks like this:
157
157
158
-
1. The web server starts the application which configures and initializes the OpenID Connect middleware. The middleware is configured with a URL from which it retrieves the metadata describing the various endpoints and encryption keys, such as the token and userinfo endpoints as well the token signing certificates
159
-
2. A request for a resource protected by the `[Authorization]` kicks off the OIDC middleware login flow
160
-
3. The user's browser is redirected to the Criipto Verify service where actual login happens
161
-
4. A callback with an issued _authorization code_ is sent back to the application and intercepted by the OIDC middleware
162
-
5. The middleware calls the Criipto Verify service to exchange the code for an _access token_. Note that this is a direct server to server call which - unlike the other communication - does not pass through the browser
163
-
6. The access token is used by the OIDC middleware to retrieve the available user information which is set as claims on the user principal.
158
+
1. The web server starts the application, which configures and initializes the OpenID Connect middleware. The middleware is configured with a URL from which it retrieves the metadata describing the various endpoints (e.g., `token` and `userinfo`) and encryption keys, as well as the token signing certificates.
159
+
2. A request for a resource protected by the `[Authorization]` kicks off the OIDC middleware login flow.
160
+
3. The user's browser is redirected to the Criipto Verify service, where the actual login takes place.
161
+
4. A callback with an issued _authorization code_ is sent back to the application and intercepted by the OIDC middleware.
162
+
5. The middleware calls the Criipto Verify service to exchange the code for an _access token_. Note that this is a direct server-to-server call which, unlike the other communication, does not pass through the browser.
163
+
6. The access token is used by the OIDC middleware to retrieve the available user information, which is set as claims on the user principal.
164
164
165
-
If you want to inspect what is actually going on you may see much of it if you use for example chrome and turn on the developer tools to inspect the network traffic.
165
+
If you want to inspect the runtime flow, the browser's developer tools (e.g., in Chrome) can be used to examine the network traffic.
0 commit comments