Introduction to IdentityServer
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 133 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/48805 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC London 201615 / 133
2
6
10
12
15
17
23
24
28
30
31
32
35
36
39
40
43
44
45
47
51
52
55
58
59
60
61
62
63
64
67
69
71
73
74
75
82
84
86
87
97
103
107
108
111
112
114
115
117
120
123
126
128
129
132
133
00:00
Identity managementSoftware developerCodeSlide ruleOpen sourceWeightSoftware frameworkMaizeServer (computing)Computer fontInformation securityBuildingIdentity managementPrototypeCodeSampling (statistics)DivisorBitService (economics)Cartesian coordinate systemAuthenticationEmailPasswordWeb 2.0Server (computing)LoginAreaCASE <Informatik>Information securityIntegrated development environmentComputer architectureQuicksortProcess (computing)Single-precision floating-point formatMultiplication signUniform resource locatorImage registrationMaxima and minimaSingle sign-onConfiguration spaceGoodness of fitRight angleLevel (video gaming)System callPRINCE2Physical systemFormal verificationGoogolSign (mathematics)Mobile appWeightComputer animation
03:40
Information securitySoftware developerCartesian coordinate systemDoubling the cubeWeightRight angleServer (computing)Mechanism designBitService (economics)Token ringType theoryCodeSystem callQuicksortDifferent (Kate Ryan album)Web 2.0HTTP cookieMobile appSoftware frameworkIdentity managementSingle sign-onPattern languageWebsiteConnected spaceClient (computing)Level (video gaming)Complex (psychology)Tablet computerWeb applicationMultiplicationComputer animation
07:38
Token ringFreewareSoftware frameworkBuildingIdentity managementComputing platformProduct (business)Control flowAbstractionSoftware developerConfiguration spacePoint (geometry)Atomic nucleusDefault (computer science)Application service providerWeightCore dumpClient (computing)Internet service providerApplication service providerServer (computing)Term (mathematics)Point (geometry)Computing platformCartesian coordinate systemSingle sign-onCASE <Informatik>Demo (music)Extension (kinesiology)Core dumpQuicksortIntegrated development environmentInformationBitCommunications protocolMiddlewareIdentity managementGame controllerService (economics)Image registrationSoftware frameworkLoginInformation securityMobile appObject modelComputer architectureWeb pageProcess (computing)Level (video gaming)Directory serviceWeightWeb 2.0Product (business)DatabaseOpen setPhysical systemCloud computingConnected spaceDifferent (Kate Ryan album)Client (computing)Multiplication signEndliche ModelltheorieMilitary baseBeta functionRight angleInterface (computing)Token ringMechanism designConfiguration spaceEmailStreaming mediaNatural numberUltraviolet photoelectron spectroscopyWritingProjective planeOpen sourceTouchscreenCodeInternet service providerVideo game consoleCodecDataflowLocal ringSpeech synthesisData conversionComputer animation
15:55
Configuration spaceLevel (video gaming)Maxima and minimaSoftware developerOvalLocal ringVirtual machineQuadrilateralWebsiteFactory (trading post)DivisorClient (computing)Electronic program guideCategory of beingKey (cryptography)NP-hardIdentifiabilityServer (computing)Configuration spaceInformationPrototypeWebsiteDemo (music)Social classFactory (trading post)Object (grammar)Semiconductor memoryProduct (business)Public key certificateSign (mathematics)DatabaseCartesian coordinate systemVideo game consoleComputer configurationMultiplication signClient (computing)EmailCodeExtension (kinesiology)Point (geometry)Service (economics)Identity managementToken ringMiddlewareLoginPattern languageObject modelUnit testingINTEGRALSingle-precision floating-point formatBitGoodness of fitSoftware testingProjective planeQuicksortMobile appRight angleSingle sign-onPhysical systemTask (computing)Execution unitPlanningSmith chartPasswordStandard deviationStructural loadComputer animation
20:51
Software developerClient (computing)Factory (trading post)DataflowVirtual machineLocal ringCartesian coordinate systemQuicksortFlow separationDemo (music)Client (computing)Bootstrap aggregatingDataflowService (economics)Connected spaceInformationCodecDifferent (Kate Ryan album)Perspective (visual)Type theoryProcess (computing)Insertion lossToken ringCommunications protocolUniform resource locatorOpen setServer (computing)Scripting languageComputer animation
22:05
Software developerFactory (trading post)Client (computing)DataflowDivisorLie groupWebsiteOpen setUser profileEmailCodierung <Programmierung>Electronic mailing listDean numberString (computer science)2 (number)Category of beingUniform resource locatorExpressionProfil (magazine)Identity managementConfiguration spaceEmailKnowledge-based configurationCartesian coordinate systemLatent heat1 (number)Mobile appIdentifiabilityProcess (computing)Object modelPhysical systemRevision controlUnit testingType theoryInformationClient (computing)Integrated development environmentSubsetElectronic mailing listTerm (mathematics)QuicksortDatabaseBitComputer fileServer (computing)User profileRight angleService (economics)BuildingSign (mathematics)Function (mathematics)Standard deviationError messageSystem callComputer animation
27:07
Software developerFactory (trading post)Decision tree learningPasswordLevel (video gaming)Maxima and minimaCartesian coordinate systemVideo game consoleServer (computing)Identity managementClient (computing)Figurate numberCommunications protocolConnected spaceSign (mathematics)AuthenticationCategory of beingMiddlewareService (economics)HTTP cookieMobile appToken ringOpen setComputer animation
28:28
Software developerConfiguration spaceAuthenticationMaxima and minimaLevel (video gaming)PasswordSpacetimeLink (knot theory)LoginInformation securityService (economics)TouchscreenServer (computing)Mobile appSoftware developerProduct (business)Cartesian coordinate systemInformationToken ringLink (knot theory)Identity managementAuthenticationWeb 2.0EmailAddress spaceCommunications protocolWeb applicationDependent and independent variablesType theoryParameter (computer programming)Uniqueness quantificationSign (mathematics)Uniform resource locatorSingle sign-onPhase transitionTerm (mathematics)Right anglePoint (geometry)Home pageAttribute grammarComputer fontSoftware frameworkInternet service providerInformation securityTwitterProfil (magazine)Client (computing)Source codeComputer animation
31:19
WeightApplication service providerSoftware developerLoginPasswordClient (computing)Demo (music)Cartesian coordinate systemUniform resource locatorMobile appRight angleInformationAddress spaceEmailSemiconductor memoryLoginSign (mathematics)Workstation <Musikinstrument>Computer animation
32:12
Error messageServer (computing)Software developerInformation securityQuadrilateralClient (computing)Demo (music)Error messageCartesian coordinate systemMiddlewareSoftware bugComputer animation
33:08
Software developerPoint (geometry)QuicksortCartesian coordinate systemIdentity managementServer (computing)Communications protocolConfiguration spaceGoodness of fitWeb pageRight angleHTTP cookieLevel (video gaming)Computer animation
34:03
Configuration spaceSoftware developerAuthenticationDependent and independent variablesMiddlewareHTTP cookieNormal (geometry)Connected spaceDivisorProfil (magazine)Level (video gaming)SpacetimePasswordMobile appCommunications protocolEmailIn-Memory-DatenbankInformationUniqueness quantificationSemiconductor memoryDatabaseSource codeComputer animation
34:55
Software developerRight angleAdditionServer (computing)HTTP cookieMobile appIdentity managementWeb browserService (economics)Sign (mathematics)Single sign-onLogin2 (number)Source codeComputer animation
35:45
Software developerLevel (video gaming)Maxima and minimaOpen setBit rateType theoryIdentity managementElectronic visual displayRight angleToken ringComputer animation
36:36
Software developerElectronic visual displayThomas KuhnOpen setAuthenticationView (database)Address spaceEmailClient (computing)Multiplication signRule of inferenceSingle sign-onIdentity managementCodecServer (computing)TouchscreenHTTP cookieSign (mathematics)Single-precision floating-point formatCartesian coordinate systemComputer animation
37:34
HTTP cookieClient (computing)Software developerLoginService (economics)Type theoryOpen setSound effectHTTP cookieCodecTouchscreenConfiguration spaceSign (mathematics)Connected spaceMobile appLatent heatBitMechanism designCartesian coordinate systemSoftware frameworkPhysical lawGoodness of fitSource codeComputer animation
39:19
Client (computing)Software developerLoginIdentity managementServer (computing)Service (economics)Token ringProfil (magazine)DatabaseMereologyGoodness of fitCuboidUniform resource locatorDemo (music)Client (computing)TouchscreenTerm (mathematics)Process (computing)PasswordProduct (business)Cartesian coordinate systemComputer animation
41:19
Software developerMultiplication signDatabaseService (economics)Mobile appInformationCartesian coordinate systemClient (computing)TouchscreenGreen's functionComputer animationLecture/Conference
42:06
Software developerClient (computing)EmailDataflowSession Initiation ProtocolService (economics)Configuration spaceCartesian coordinate systemClient (computing)Projective planeMobile appSingle sign-onWeb 2.0Computer animation
42:57
Software developerAuthenticationData typeUniform resource locatorContent (media)Directory serviceToken ringConfiguration spaceOvalClient (computing)DataflowElectronic visual displayIdentity managementProjective planeMathematicsGame controllerUniform resource locatorWeb 2.0Process (computing)Software testingAuthorizationElectronic mailing listAttribute grammarType theoryDefault (computer science)Server (computing)Configuration spaceMobile appElectronic visual displayIdentity managementValidity (statistics)CodeCASE <Informatik>Right angleComputer animation
45:13
Token ringData typeDependent and independent variablesEmailSoftware developerRule of inferenceIdentity managementOpen setClient (computing)DataflowError messageGoodness of fitPerimeterCartesian coordinate systemMobile appSingle sign-onAdditionComputer clusterParameter (computer programming)Token ringComputer animation
46:05
Software developerData typeDependent and independent variablesClient (computing)Dean numberDataflowDecision theoryDemo (music)LoginRingnetzTouchscreenMobile appClient (computing)InformationIdentity managementMiddlewareCodeToken ringCartesian coordinate systemBitComputer animation
47:02
Software developerEmailDependent and independent variablesData typeClient (computing)Token ringDirected setIdentity managementCodeToken ringInformation securityWeb 2.0AuthenticationMultiplication signHTTP cookiePattern languageCommunications protocolEvent horizonSurfaceBitGoodness of fitData storage deviceSystem callCartesian coordinate systemMobile appSource codeComputer animation
48:24
Software developerClient (computing)Demo (music)Mobile appToken ringOpen setPhysical systemWeb 2.0CodeProcess (computing)Data structureInformationCartesian coordinate systemUniqueness quantificationService (economics)Right angleComputer clusterComputer animation
49:43
Client (computing)Software developerSynchronizationAuthorizationDependent and independent variablesError messageToken ringView (database)Data typeAuthenticationConfiguration spaceOvalInformation securityIdentity managementCodeToken ringWeb 2.0String (computer science)Uniform resource locatorServer (computing)AuthenticationService (economics)AuthorizationIdentity managementCartesian coordinate systemInformationMereologyEmailValidity (statistics)MiddlewareRight angleTouchscreenResultantProcedural programmingMultiplication signCovering spaceAttribute grammarNumbering schemeComputer animation
52:09
Software developerError messageContent (media)Directory serviceMultiplication signMobile appToken ringAuthorizationWeb 2.0CodeInformationService (economics)Cartesian coordinate systemServer (computing)Identity managementHTTP cookieSystem callComputer animation
53:00
Internet service providerSoftware developerAtomic nucleusSample (statistics)Source codeIdentity managementServer (computing)Cartesian coordinate systemOpen setValidity (statistics)Configuration spaceBitType theoryMultiplication signPoint (geometry)DataflowCommunications protocolCodeSampling (statistics)Web 2.0Token ringBuildingMobile appTerm (mathematics)HTTP cookieRight angleFile formatMachine codePrice indexSelf-organizationForestWeb browserInformationComputer configurationDifferent (Kate Ryan album)GoogolSingle sign-onFacebookExtension (kinesiology)Connected spaceApplication service providerAuthenticationSoftware frameworkComputer animation
57:36
Sample (statistics)Source codeSoftware developerIcosahedronIdentity managementInternet service providerMobile appServer (computing)AbstractionProcess (computing)Point (geometry)InformationSingle sign-onAuthenticationView (database)Cartesian coordinate systemHTTP cookieFacebookIdentifiabilityDatabaseWeb 2.0QuicksortService-oriented architectureCodecLaptopConfiguration spaceDemo (music)Local ringComputer configurationTouchscreenPay television2 (number)Gateway (telecommunications)CASE <Informatik>Computer architectureGoogolWeb pageVideo gameSign (mathematics)Service (economics)Absolute valueRight angleProduct (business)Computer animation
01:02:18
Software developerSample (statistics)Source codeComputer animation
Transcript: English(auto-generated)
00:08
So, welcome. Thank you, everyone, for coming to this session today on Identity Server. My name is Brock Allen. I'm the co-author of Identity Server along with my colleague
00:20
Dominic Beyer and this is something we've been working on for a couple of years. It's a technology that we are really excited about, really passionate about. We really enjoy applying Identity Server and the architectural principles behind it to help us solve our customer problems. And so, you know, that's what we're going to talk
00:41
about is Identity Server and how you can get a little bit of understanding about what Identity Server is and how, you know, what it can do for your architecture. And so then what we're going to do is talk about basically getting started with Identity Server, the bare minimum that it takes to configure Identity Server, get it
01:02
running, and actually start to build a little sample application where you can start to, you know, prototype it and perhaps, you know, use it in your environment. So at a high level, the question is, you know, what is this thing called Identity Server? You know, you may have heard of it, has something to do with security, and
01:21
in fact, that's exactly what it's about, is helping you build security into your applications. Now, security is a very broad topic and so there are two areas of security that we focus on. The first has to do with something called single sign-on and the other one has to do with protecting your web APIs. Identity Server can just do one or the either or
01:42
it's best when you use these two together. So just in case you've been living under a rock for the last five years and don't know what single sign-on is, I'll just, you know, briefly cover that. So the idea here is that you have an application, you know, you want your users to come in and log in, okay? So of course, they're going to
02:02
provide credentials into your app, you know, you have some amount of code that does the authentication for those users, you know, maybe you have a registration system, maybe you have some sort of email verification, two-factor auth, password reset, you know, maybe even your Google logins, and so that's all well and good. But of course, there becomes a problem when you start to have more
02:24
than one application, right? That plumbing code that deals with security ends up getting replicated multiple times. So that's not an ideal situation. So an architectural solution to this is to take all of that plumbing and factor
02:40
it out into a single location, right? And so this single location becomes a centralised application called the token service where it manages all of those things, and the job of the token service then is to provide authentication to the rest of your applications. So now what's going to happen with this
03:00
sort of architecture is your users will come in, they will sign in once to this token service, and then the token service will convey the identity of the user over to your various applications, okay? So this thing at the top, this is called a token service to provide you this nice consolidation of
03:20
features, your users, right? The nice thing about this, they only have to log in once, right? They can have a really good password, all goodness. This is what Identity Server provides you with, okay? So Identity Server is a token service, and it can provide you this feature of single sign-on.
03:41
The other thing Identity Server is going to help with is securing your web APIs. Now, web APIs, given the fact that you can have lots of different application types, a little bit more complex, but the high-level idea is you have some sort of application that wants to use a web API. So maybe you have a web application like an MVC application,
04:03
and there's this web API out there that you want to invoke, and of course you want to do it securely. So your application, maybe it's from JavaScript, you want to invoke this web API, right? Very logical thing to want to be able to do. And of course that API has to have some intelligence on how to protect this API and make sure that
04:21
that is secure call. How do you do that, right? Maybe cookies or something else, not sure, something you have to figure out. Now, APIs, right? You want to reuse these from lots of different scenarios. So you might want to invoke this exact same API from the server-side code instead. Do you use the cookie still there or, again,
04:41
some other mechanism? Maybe not the cookie here because the server-side code may not have a cookie with a back-end API. Of course, it gets more complex once you start to throw in mobile applications in here, right? Maybe you have a native app running on your tablet or your phone. It, of course, wants to invoke the API, and, again, different type of credentials, maybe, not sure. It gets more complex
05:05
as well for the client application, right, this mobile app, if it actually wants to invoke multiple APIs. So you can imagine the scenarios get more and more complex. Again, maybe you want to have an API call another API on behalf of the user, kind of like the double-hot problem,
05:21
and you want the identity of the user to propagate. These are very complex things that you need to sort out. And another web API scenario is where you have applications like a server application, you know, without a human, trying to invoke an API as well. Those are another scenario that you need to think about securing. So the problem here is a very similar problem to what we had for the single
05:44
sign-on problem, which is you have this plumbing code, right, this credential management code that has to juggle all the different ways a connection can be made into your web API, and, of course, you need to secure that. So, again, the architectural
06:00
pattern here is very similar to the single sign-on pattern. The idea is you're going to take these credentials, move them out into something centralised, and you're going to let it deal with all of the juggling of the different applications. So that's another thing Identity Server will provide you with is a mechanism to issue these things
06:20
called tokens to your applications, and so it knows how to communicate via the various mechanisms to these various apps to allow them to connect to the token service. They get back something called a token, and then that token can be used to invoke your API. And so the nice thing now is that your API doesn't have to really
06:41
worry too much about which type of device is connecting. It just needs to know how to receive these tokens, and that's enough to secure your web API. The nice thing, then, these tokens can be used across multiple APIs, and, again, the token service knows how to deal with all these other scenarios, you know, server-side applications getting a token, your mobile apps getting
07:03
tokens, and, of course, even your headless applications getting tokens. And even the more complicated scenario, which is the double-hop problem, when a request comes into a server-side application, it wants to call your API, and you need to get another token to then call a back-end API from there, passing
07:22
along the user's identity. These are all very complex things that we need to figure out how to do, and the nice thing about the token service is it will abstract all of that out for you. This is another thing that Identity Server does. Okay. So, basically, again, okay, great, Identity Server
07:42
provides us this mechanism. So a little bit more details about what Identity Server is. So, Identity Server is a framework for helping you build this token service. It is written in .NET, it is free, it's open source, and the two protocols
08:00
that it is implementing to provide you this single sign-on and Web API security are OpenID Connect and OAuth 2, which, of course, are the modern protocols for doing security. Now, there are a lot of products out there that are also token services. So how does Identity Server sort of
08:21
relate to those? Well, or, you know, or even why would you use Identity Server over some other product? So the thing about this is Identity Server is not a product. It's a framework. So the idea with this framework is that it is designed for flexibility and customisation. So the idea is
08:41
that you host Identity Server, and, in fact, you build the token service product yourselves because you need this flexibility or customisation that maybe some of the other products don't have. What's an example of some of these scenarios? Well, like UI branding, right, if you want to
09:01
control the user experience, you know, what your user sees when they come in through your whole login process, of course, that's easy to do, and, in fact, all the other products have that sort of feature as well. Identity Server gives you more control and more flexibility, though. So a very common scenario is you might have a custom database, and that custom
09:21
database, or even that legacy database, has all of the users of your system. That might be very hard to take that legacy database and have some sort of cloud provider know how to communicate with it, or, you know, off-the- shelf product will wire up to that database. You might create a brand-new project, in fact, ASP.net, maybe using ASP.net identity, and you want that to be your
09:43
database of your users. So that's one example of why you would do, you need the control or want the customisation. Another scenario for customisation for Identity Server is user workflow. So, again, like I said, you can brand, you know, the user pages, the login screen, and things like that to give the user
10:04
experience, you know, what you want it to be for your environment, but you might want to control more than just that, like the workflow of the user as they come into your system. You may have some sort of custom registration process that you need to take the user through, or when users log into your applications,
10:21
there's some sort of workflow you need them to go through. A common example we have is when sometimes users come in and, for your application, they need to sign a licence agreement, right, before they can continue on to the other pages. That's code that you could write in each of your applications, but, of course, pushing
10:40
this up into the token service makes much more sense because it's upstream from all your apps. So, that's another example of what Identity Server can do. Now, you still may need to use some of these other products, for example. Maybe your users are actually
11:00
coming from Active Directory, and you have an Azure Active Directory set up. Well, that's okay. It turns out Identity Server, it can be used standalone, or it can be used in conjunction with these other products. That's a really nice use case for Identity Server. So, you have a scenario where you want to control what happens when users come into
11:20
your apps, but some of them might be, some of the users might be coming from your custom database, or Active Directory. An example of that would be like a customer, right? They would be living in your local database, whereas an employee coming in would come in through something like an external provider, like Azure. So, that's another very common use case for Identity Server, and, again, it gives you the
11:42
control and the flexibility you want for your application design. So, kind of the way we think about Identity Server is that, you know, Identity Server, with you hosting it, you controlling it, and you configuring it, gives your, it provides like an identity platform for your applications. So, that's a
12:03
high level of what Identity Server is about. So, in terms of the architecture here, Identity Server is designed as middleware. What this means is that you're going to build a hosting application, right? That's kind of the whole idea with customizing this stuff. You're going to load this thing up. You're going to pull it in as middleware into your
12:21
hosting application, and you're going to configure it with, you know, information about your environment so that Identity Server knows how to do the protocol bits for you based on your applications and your users. That's basically what I'm going to focus on in terms of my demo. There are, you know, lots of other extensibility points
12:42
within Identity Server, and so I'm probably not going to talk, you know, too much detail about these, but, you know, almost every aspect of Identity Server is replaceable with some sort of, you know, interface that you can plug in. In terms of the platforms that we support, Identity Server 3 was
13:03
released about a year ago now, and it is Owen and Katana based. So, that means it runs on, you know, the current version of .NET. It actually turns out it runs on ASP.NET 5 already, but only under the full .NET framework, and we actually even have some users using Identity Server on
13:22
Mono. So, right now, it's actually, you know, cross-platform. We just this week announced Identity Server 4. Identity Server 4, well, we announced a beta of it this week, and we plan to release it sometime, you know, around the release time of ASP.NET 5, and what we did with
13:42
Identity Server 4 is we ported over most of the core engine from Identity Server 3, but now we are, our hosting model is based on ASP.NET 5, and really what that affords us is the ability to run on the core CLR .NET core. So, now, anywhere, you know, ASP.NET 5 runs, you can run
14:02
Identity Server 4. All right, and this is the last slide, and then I'll switch to code, I promise. So, this is what we're going to talk about in terms of configuring Identity Server, and this is the core object model that you have to be aware of in terms of your, you know, designing Identity Server, putting it into your
14:22
environment, and figuring out, you know, how to get it up and running. So, these three main things that you need to teach Identity Server about is, first, your users, right? That's the whole point of Identity Server. It's customisation. It's your user database. You want to control all of these things, so you need to tell Identity Server about your users. So, that's the first thing. The next thing you
14:43
need to teach Identity Server about are what are called your clients. The client is the application. So, this is the application that wants single sign-on, or it's the application that needs a token to go call a web API. So, Identity Server, again, because the protocols are all accommodating for these
15:02
different scenarios, right, can deal with JavaScript apps and mobile apps and web server apps and so on and so forth. And the last thing you need to teach Identity Server about is something called a scope, or the scopes of your configuration. Scopes are basically the resources that an application is trying to get to, okay? What
15:22
that means is maybe an application is trying to log the user in, so they might need to have information about the user, like their email or their name. That is called an identity scope. Or if an application is trying to call a web API, it needs to access a resource scope, okay? So, scopes allow
15:40
you to model, in essence, the things that Identity Server are protecting, okay? So, those are the three main things in terms of the object model that we need to know about. All right. So, the rest of this is I'm just going to write some code and show you how to get this up and running. So, to start
16:00
with, I have two projects. I have a brand-new, almost brand-new console application. This console application is just loading Katana, all right? Self-hosted. And, really, we're just setting up some logging. So, this host is going to be my token service, and
16:22
I'm going to load in Identity Server here to issue tokens. So, it's in here that I'm going to do my configuration for my users and my scopes and my clients. The first thing I need here for Identity Server is the token service, right, is issuing tokens, of course, and these tokens are going to be signed. So, that's
16:41
one other bit of configuration information that you need is some sort of X.509 certificate. This is not your SSL certificate, it's a separate certificate for issuing your tokens. And now that I have that loaded, I can go in and plug Identity Server into the pipeline. So, here is just, again, a Katana
17:01
pipeline. Our middleware is used, in the same pattern that you see all other middleware being used, and so we have a use Identity Server. And to this, what we configure is the Identity Server options. So, there are a couple of properties here, like, you know, site name, so NDC, sorry, demo. I need to configure the
17:21
signing certificate that I loaded. And the last thing is I need this thing called a factory. The factory is where you are going to teach Identity Server about your object model. So, your users, your applications, and these scopes that you're
17:41
trying to protect. Okay? So, what I'm going to do is go create some, just some configuration here in memory. So, the first thing for the users, okay? What I'm going to use for users is actually just an in-memory collection. So,
18:00
this in-memory user is just an object that we have or a class that we have in Identity Server. It's useful for doing demos, for doing prototyping and things like that when you don't want to plug in, like, a real database of your users. It's also used in our unit tests, right? When we do our unit tests and our integration tests, rather than having a full-blown database, this is
18:21
what we use. So, that's what I'm going to use here. Now, of course, the whole point of this is to plug in your user system. So, this is one of the extensibility points in Identity Server is the ability to replace this with your own custom, you know, so what I'll do is I'll just create a, you know, a test user here, and I will give
18:42
that test user a username and a password, and the other kind of things that the user is going to have is, of course, claims, claims of the information, the identity information that the token service is going to be providing to your application. There is a claims collection
19:00
here. Again, this is just an in-memory collection, and I can put whatever claim I want, so maybe this person has a name, right, Alice Smith, and the user could have other things like roles and email and so on and so forth. The other
19:24
claim that I need to provide here is something called a subject claim, and so this is so special that we have a separate slot for it. So, the subject claim is the unique identifier for the user, okay, and so what will happen is as every time the user logs
19:41
in through Identity Server and that information is passed over to your app, that subject identifier is that unique ID, so the user's name and the email, that might change over time, but the subject ID will always be the same, okay. So, just for this demo, I'm going to hard code it, value 123. This might think, you know, you might think of this as like the
20:00
primary key for the user, okay. I don't think I would use a primary key out of a database, right, because like that might change, but something like a GUID is probably a good value to use here. Okay, so that's my quote unquote database for Identity Server and again, this is obviously, you know, replaceable with
20:20
something more production ready, but good for getting started. So, the next thing I need to configure are the clients. So, the client represents the application that is trying to use Identity Server to do single sign on, for example. So, what I'm going to do here is set up a client,
20:42
okay, and I'm going to set up a client ID and a few other things like client name just to get my demo going. Now, for my client, I actually have another project running here, and this is a MVC application. So, this is a separate MVC application. There's really not too much code here. It just has sort of the standard, you know, MVC bootstrap,
21:01
all that basic stuff. And so, what I'm going to do is I'm going to register this application as my client. So, I'm going to give it a name of something like MVC, you know, this is going to be my MVC demo client, for example. And we need to know a few more things about this application. Recall that I said that the protocols,
21:22
OpenID Connect and OAuth, they know how to accommodate the different application types, right, like a JavaScript application or a server-side application. And so, we need to know that information when configuring the client, okay? So, this is going to be using something called the implicit flow. And again,
21:41
these represent the different kind of ways that clients connect and get tokens. I need to set up something else, right, which is something called a redirect URI. The redirect URI is how the token service knows where to send the tokens, right, to the application. So, this in essence is, you know,
22:01
the application's URL from the token services perspective. So, actually, what is that? I'll go look at my properties here. I think that's the URL I will be running in IIS Express. And I will put that in here like this. Okay. Do we have anything else? Oh, yes,
22:23
one more thing. Allowed scopes. So, remember what I said scopes were? Scopes represent the resources that the application is trying to request. So, what I can do is put in here the things that we will release to this
22:41
application. So, I'm allowed to send the email of the user or the name of the user and things like that. So, actually, I haven't configured any scopes yet. So, that's actually one more thing I'll plug in here real quick are then the scopes. So, again, scopes represent the
23:01
resources that you are going to make available to applications or that they are going to try to get access to. So, there are two types of scopes, like I said, identity scopes and resource scopes. For now, I'm just going to do single sign-on. So, I am just going to put in here scopes that represent information about the user. Now, one of the things that
23:21
the application will want to know about the user, well, it's basically these claims. So, scopes for these identity sort of resources ultimately are going to map to this information about the user, these claims. So, there is actually a scope that allows me to say I want to know the unique idea of the user. There
23:40
is a scope that says I want the, you know, email for the user. There is a scope for your name and your profile URL and your picture and things like that. So, that's the next thing I need to set up here. So, actually, the specifications that we are using, OpenID Connect, they have the concept of a few predefined scopes. So,
24:03
we actually have constants for these. There is one called OpenID. This is where you can say you are going to release the unique identifier for the user. Profile represents things like their name, standard scopes.email represents things like their, well, email. And
24:21
you can come up with your own custom scopes as well. So, creating a scope, right, scopes just have a name. One of the ones that is not predefined by the specification is something about their, like, role, for example. But if you have custom information that you want to model here, you can do that.
24:40
So, I will call something called roles, and then I can say, yeah, go ahead and release the role claim as well. So, this is an identifier, that's what scopes are, an identifier for a list of claims that we are going to release to the application.
25:00
Okay. I think with these three things, I'm going to configure one extra little bit of configuration here. I will come back to those later. And so, now that I have some basic object model configured for identity server, I can then say use these clients
25:22
and use these users and scopes, client scopes and users. Now, again, in terms of
25:40
this configuration here, I'm hard coding the configuration. That may be totally appropriate for your environment, right? In these, like, you know, more highly automated build systems where, you know, you need all, you do all your source control and that kicks off a big, long process where it runs through your automated build
26:00
and your unit test and then even an automated deploy. Some customers of ours, especially if they only have, you know, one or two apps that they need to get configured, this is a perfectly acceptable configuration system for them. You know, would you need to go set this up in a database? I mean, you could, but some environments don't mandate it
26:20
or, in fact, don't even want it. So, anyway, the configuration I'm showing here but if you decided to, you could move it to a configuration file or even to a proper database. Okay. Ah, and so that's the last thing I forgot to do is say what scopes we are allowing. So,
26:40
we're allowing the OpenID scope, the email scope, maybe the profile scope and the role scope. Something like that. So, these identifiers are mapping to the resources that we're saying that app's allowed to get them. Maybe for a different app, you wouldn't want to allow that, so you
27:00
wouldn't include it in the list. Okay. I think that's the basics here. Let me just run this. So, what we should see is a console application pop up, right? So, again, Identity Server is open and Katana hosted, so you can run in any of those hosts. And we have
27:32
a sign-on. So, again, the protocol for this is OpenID Connect. There's middleware then for this.
27:40
And the middleware is the use OpenID Connect authentication. And this is where we have to configure our client to then, of course, trust the token service. So, there are a few things about this thing here that we need to configure. I'm going to just name the middleware as OpenID Connect.
28:01
There's a property here that then when this application takes the user to the token service for authentication, the token service returns a token back to the app. And then we need to log the user in. And so that's why I have the cookie authentication middleware already registered here. So, there's the cookie middleware.
28:21
I need to tell the middleware what is the token service is running here. don't know if you guys noticed or but in the main here is where I'm setting up. All right. That's the URL for this. Actually, we could even go here to see if it's running.
28:42
And in fact, there it is. Nice pretty UI here. This is really just like a welcome screen for developers just to be able to look and see if something you probably would disable in production. But the other thing about this is that now this is the running server that the app is going to need to communicate with and
29:00
it does so via this this discovery document. So that's how the application the MVC application is going to discover information about how to communicate with this thing. So that's the other thing I need to put in here. Right. We
29:20
have that redirect URI that was the URL of this app. And what else do I need here? Response type. This is a parameter in the protocol that says what do I want back from the token service. Remember it's supported two
29:40
things. Single sign on and doing web API security. So for single sign on I need to ask for something called an ID token. That basically tells me information about the user. And I feel like I'm missing one more parameter. Yeah, scope. Okay. And the
30:00
last thing then is what do I want back from the token service in this ID token. I need information about the user. So what I want is the user's unique ID. I want their profile. Maybe I want their email address for example. Okay. So this is how you indicate that
30:20
information. So in terms of my app then, what I have here is just simple web application from the home page. What we do is you can click the secure link. That is then going to trigger the authentication phase. Now of course, how do we authenticate?
30:40
Well, we need to make our app secure, right? So you can throw the authorized attribute on this thing, right? And this will say, hey, the user's anonymous. We need to get them to go log in. That will trigger the redirect off to identity server, which point will come back. And in here then, what I can do is show you the
31:00
information about the logged in user. So I run this. Oh, I went to the wrong URL first. There
31:20
we go. So here's my application. I clicked the secure button. Right. That's exactly what's supposed to happen. Right. You're not allowed into the app. You go to the centralized location for signing in. Right. We'll log in with that in-memory user
31:40
that I had configured. Right. And click log in. The next thing we see here actually is what's called the consent screen. This is where the user has the last chance to say whether or not they want to really continue on to the application. Right. This information about the user is going to be released to
32:00
that app. Okay. And so, you know, the user can choose and say, well, no, I don't really want to give them my email address. And so you can hit yes or no. And so as you then continue back to the application. Okay. Uh, awesome. You guys ever seen this error before? This is, I
32:20
think, a bug in the Katana middleware. All right. I thought this was updated. All right. Typical. Let me close my browser and start again.
32:57
Oh, did I put the wrong one in there?
33:05
Yeah, but that's not the one I have configured. That's okay here. Let me go to this one here and make sure that that one. we go. Okay. Sorry, I think what happened here is when I launched for
33:20
some reason. No. Yeah, it did took me to the SSL one. Okay. Anyway, here we are. So that is a good point though. You should be running over SSL, of course, right, for not only your cookies, but all the data that's going to be in the page. So that sort of goes without saying. So,
33:40
great. We're now logged into our application. So what ended up happening there is we took the user to Identity Server. Identity Server did all of the protocol details for you, but you worked with the users and the application configuration that you taught it about. Okay. And it successfully got us back over to the application.
34:00
And at this point we're just using know normal cookie middleware and the OpenID Connect middleware from Microsoft. Okay. Now what did we get? Let's go to our claims that we saw here. Some of the claims that we get back are protocol level claims.
34:20
You know these are something that you might want to filter out back in your app because these do take up space in your cookie. but the things that you really care about here are the user's unique ID. This is the subject claim. So that was that one two three that I'd set up in my you know in-memory database for the user. There's information about how they authenticated. So they used a password
34:40
to authenticate as opposed to you know two factor off or something else. Here then is the profile information like the user's name, their email and so on and so forth. I don't think I got my roles. Well, it's because I didn't ask for them. Okay. So if I wanted the roles in
35:00
addition, right, I could ask for this additional scope. Come here and log out now, which gets rid of my cookie. Go back to the token service. Actually, do you guys notice what didn't happen here the second time? Yeah, I didn't get authenticated again, right? Or, rather, I wasn't prompted for credentials
35:20
again. Why? Well, that's what single sign-on is about, right? The user already had a login session with Identity Server. So from that same browser, when we went back to Identity Server, it said, yeah, you're already logged in, okay? So just immediately took me back to my app. So here now, in my app, I now should have my
35:42
do you see a role anywhere? Yeah, you're right. Where is that? Okay, we have a role claim for Alice.
36:00
I said it was okay to do roles. I probably should give this thing a display name. Oh, you know what I forgot? Anyone know? When I talked about scopes, I said there were two types of scopes, right? What did I, I forgot to tell it
36:20
which of the two types of scopes this was. So there's actually a type here that I forgot. Okay, so this scope is something called an identity scope. Okay, so that would have been included in the identity token. I didn't configure it this way, so we didn't get that. So let me shut down my little console app, re-run this,
36:43
go back to my client and I
37:02
don't we're now being asked about the rules. so hit yes and here we are. So the consent screen showed back up again because okay. So
37:21
that's in essence single sign on. that's the basics bare bones of setting up identity server for that, any questions, say again, single log out is supported. Okay, So what you can do is, in your application, when I do logout right now, I'm only logging out of cookies.
37:43
So you could even pass in, you know, open ID connect, log out there as well. You could pass in, you could pass nothing, and you end up, it's the same effect basically. And what this is, in essence, is going to do is trigger the redirect over to the token service
38:02
to sign you out there. In fact, we could do this by doing a void. Turns out we don't even need a return type here. That, in essence, triggers the redirect. So now, go to my secure page, just to see if I'm still logged in.
38:24
I hit logout, and now we're over on the token service. Now, there are ways to avoid the prompt as well, but that's also possible. Also, after you've logged out, there's a way to then go back to the application that you just logged out of, if you would like as well.
38:42
A little bit more configuration to be done, but that's that. This also supports some of the newer specifications around open ID connect for doing sign out everywhere. So what will happen is, if you're logged into multiple applications, and you've logged into all of them, this sign out screen has a mechanism for notifying
39:03
all the other apps that you had logged into. Essentially, depending on which mechanism you're using, it does it with an iframe, and the iframe then can go off and let those apps know that they need to clean up their cookies. Okay, good.
39:21
Other questions about this? Yeah. If the user wants to change their password? So, identity server is the token service part of this. The profile management, the user management,
39:42
remember, it's your user database. So it's your job to do those things, okay? And in terms of, you know, if you want a screen to change their email or change their password, that code that you would write is just another application, another client application to identity server.
40:03
Okay? All right. Good. Another question. Yes?
40:27
So the consent, so let me try to understand. So you're asking about if the user gives consent and then things all shut down and then you try again tomorrow, do we re-consent? So I don't know if you recall.
40:42
And I need to change that URL just so my demo keeps working.
41:02
So bear with me while I rerun this. So first thing, what I'm going to show you here in a second, if this will ever come back up. Oh, I lost something here. When the user is provided with the consent screen, there's a check box where you can say, remember my consent. And so that consent can get stored in the database.
41:22
And so the next time the user comes in and it's the exact same request for the same scopes, there is no prompt, okay? If the app is asking for more or different consents, then we have to re-present the consent. But the other thing about the consent screen is the consent screen is
41:43
usually only appropriate for third-party access where the token service is not the same company as the client application. And so that makes sense because it's third-party. The token service is guarding this information to release to this third-party app,
42:01
and so the user needs to be involved. But in the scenario where the application and the token service, they're all from the same company and the user is probably also from that company, it doesn't make sense to do consent, okay?
42:23
So you can disable that. That is just a configuration setting for this client application, okay? Require consent false, for example. And you can enable and disable that client by client. Your internal apps, turn it off. External apps, you enable.
42:42
Okay, so right now we have single sign-on. The thing I don't have yet, though, is the Web API piece of this, okay? I haven't done that yet. So I have yet another project here, and this is a Web API project. And this Web API project is basically another Katana project.
43:01
I'm loading in Web API here into the pipeline. I have a little controller here, and right now this controller's job is to, you know, just echo back who the caller was. So if I run this, I wonder if my URLs got changed.
43:21
Okay, apparently not. So if I go to test, right now, you know, I'm not authenticated, okay? And in fact, I'm not even being denied, okay? So again, same kind of idea here is that you want to protect this thing, so you want to put this good old authorize attribute, right? At least that's one step towards doing your authorization. So what I now need to do, though,
43:41
is I need to somehow figure out how I'm going to secure this from Identity Server. So Identity Server can also issue a token for invoking Web APIs, and we can deliver that token to the MVC app. So there are a few things I need to do. I need to register this Web API as a resource in Identity Server
44:03
that Identity Server's protecting. So that's going to be another scope, right? It's a resource-style scope. So I need to do that configuration in Identity Server. I need to then configure my... Sorry, wrong project here. I need to then configure my app
44:20
as being allowed to get that scope. I need to change my app to request it, right? And then I need to use that at the Web API, and then let the Web API receive the token and do validation on it to make sure the user's really allowed to call the app. So a few more configuration steps here. First, let me set up a new scope
44:40
that represents my Web API. Okay, so this is going to have a name. I'll call it API1. I'll give it a display name, some API. And the type is, of course, in this case, resource, which, as we just saw a few minutes ago, is the default value, okay? So that's how we model our API in Identity Server.
45:03
I now need to say that this MVC app is allowed to get access to that. So that's another allowed scope, okay? And I think that's probably all I need here. Let me restart the server. Yeah, good.
45:20
All right. And then now in my MVC app, the way you now request, in addition to the single sign-on for the ID token, you now want the access token. There's another parameter here we passed, which is called token. And that basically says,
45:40
deliver now an access token to the application. And the access token, what's it for? Well, it's for use at this particular resource at API1, okay? So if I were to run this now,
46:09
and what did I not do? Log out. Oh, I disabled consent, didn't I? Well, there we go.
46:20
I wanted to show it in the consent screen. Sorry about that. Well, I guess it shows you what the consent, or the lack of consent looks like. Okay, here we go. That's what I wanted to show you. So now we are requesting access, not only for some identity information for the user, but also this access to this resource.
46:42
So imagine that is your calendar API, right? And the client's trying to use your calendar. This is letting your user say if this app is allowed to or not. Again, that makes sense in the third-party scenario. So what we end up getting is back, is something called an access token to the app. The app, or rather the middleware in the application,
47:03
unfortunately doesn't do anything with the access token. So you have to go grab the access token yourself. So you have to write a little bit of code to actually preserve it. And the way it's a surface to you, is that there's a thing called the notifications. And there's an event called security token validated
47:21
that you have to wire up to. And you, in this event, this is after all the security protocol stuff is done, and we're sure who the user is. What they provide is the access token here. So this access token then is for you to then store somewhere.
47:42
A very common pattern is to take this access token and just put it in to your cookie as a claim. And so then every time the user comes back into the MVC app, you can read the access token out of the claims and then call the web API. So I'll do that by doing the authentication ticket,
48:01
I'll see the user, and I will add a claim here. I'll call it access token for that token. Okay? Yeah, I think that's good.
48:31
Rerun my app. Okay, I'll go and try to get my login. Again, asking for consent. I do this, and if I did it properly, look what we have down here.
48:42
That's my access token. Anybody know what this is? What kind of access token? A JWT, yes. So this is a JSON web token. And so a JSON web token is a JSON encoded,
49:01
a JSON data structure that represents the information about the user who is going to be using this access token. So it has things like the user's unique ID, for example. And it also has the information about where the access token is allowed to be used. So I will take this access token
49:21
and then send it to my web API to try to have the API invoked on behalf of that user. And the web API now's job is to validate this. We need to see that this access token comes in, that it's from the token service that we are trusting, and that the access token says, yeah, it's meant for this particular web API.
49:42
So right now, on my UI, back here, I could actually call the API, but right now the web API isn't even looking for the access token. So I actually, sorry, I'll probably show that code. So when I try to use the API,
50:02
this is where I read the access token out of my claims. I set this as the authorization header. That's the well-known location in the HTTP request that you send this. You use the bearer scheme, and you pass that token along. And then I'm just invoking my web API
50:21
and then showing the results on the screen. So let's go check my web API and see what he's doing. So again, he's not checking anything right now, and there's the authorize attribute. So there's middleware to do the token authentication.
50:41
Pretty straightforward. So I will do use identity server bearer token authentication. What our middleware will do is, it will look for the incoming bearer token, and we will run the validation procedures on it. Under the covers, we end up wrapping up the Microsoft middleware.
51:04
So Microsoft middleware exists to do this. There's some features that they are missing. So we are basically providing those features on top. And so as part of this, we need to know, well, okay, who is the token service that we are trusting?
51:21
Who's the token service that we're trusting for tokens? And so we need to put that information in there, which is actually the same. I'll just grab the string from the other guy here. That is the URL of identity server. And the last big thing are the required scopes.
51:41
Again, to call this web API, you better have a scope called API 1. That's the resource that this web API, you know, the name, the logical name of this API, and so identity server is protecting this thing. And so if the user is allowed and the application is allowed, there will be a scope in there called API 1.
52:01
So if you don't have that, you're not allowed in. So run this one more time. Again, here's my API. Hopefully it still says you're not allowed. Actually, I think I still have my access token here in my app. Let's try it one more time.
52:20
Hey, look at that. So now the server-side MVC code read the access token out of the cookie, made a server-to-server call, passing the authorization header, passing that token, and now the web API was able to check and say, oh, yeah, right, I see the token, and here is the information in the token. It represents this app trying to make the invocation.
52:43
The token is allowed to be used here at this web API, and the user is, you know, user 123, which represents our Alice who initially logged in. Okay. So that is basically the steps involved
53:02
with getting identity server set up. Basically configured to know about your environment, okay, and now, you know, you can build single sign-on for your applications, protect your web APIs, and again, there's a lot more customization, of course, beyond this, but this was the intent of the session,
53:21
was to give you this bare-bones, you know, information about how to get this all set up, okay? Some resources here for you. There is where the code lives up on GitHub. That's our organization. You can find not only Identity Server 3, but our newer Identity Server 4 up there. We have lots of samples showing you how to go about
53:41
doing what I've just shown you here. I showed you here for an MVC app, but you might be building a JavaScript application or the server-to-server application or a native application. So lots of samples that show you, you know, different configurations for maybe the type of application you're actually building. So we have some decent documentation up here,
54:01
you know, to kind of give you information about the internals of how Identity Server works and all the different extensibility points and configuration options. And again, we occasionally hang out in Gitter, so you can ask questions there. If you do want to ask questions, though, again, Gitter, or actually just open up an issue on the GitHub issue tracker.
54:21
We end up getting a lot of people asking for either questions about, you know, how can I get this to work in a particular configuration or even feature requests. So please give us feedback via the issue tracker. And other than that, I think we have some time for some questions. Yes. I'm sorry?
54:42
Oh, yeah, yeah, please use the mic or hand the mic around. Good idea. With the Identity Server 4 stuff, it's targeting ASP.NET 5. Where does that leave frameworks like Nancy and things like that in support for those?
55:00
So the question's around what's the Nancy support for? So in Identity Server 4, it's ASP.NET 5, which is kind of different to the Owen and Katana flow and things like that. So your question is what's the support if I'm building a Nancy application? Well, the Nancy application is just using the standard protocols to talk to Identity Server.
55:21
It doesn't matter if it's Identity Server 3 or 4 or however it's hosted, okay? So as long as you have something on the Nancy side that can ultimately do the validation of those JOTS. Nancy's running in, it can run in the same middleware, right, with the OpenID Connect middleware, right? So then that actually could give you
55:41
most of the heavy lifting. Other questions? Yeah. It was about what a token actually is. Is it different to a cookie or is it piggybacked inside of a cookie or when it communicates to Identity Server and sends the token back, is it inside a cookie?
56:01
Right, so the token coming back from Identity Server. So the question is what's the format of this token? What is it really exactly? It's really just something that represents who that user is, okay? Now, in terms of the details of the protocols, OpenID Connect, that token coming back from Identity Server
56:21
is a JSON web token. So that's actually what the MVC app is getting back, okay? Once that token is validated, though, it contains your claims for your user. That's how the app knows information about the user. And then the app decides what to do next. For a web application, usually you take all those claims
56:41
and you turn that into a cookie, okay? And so then as the browser uses the application, the cookie is sent back. So you're trading the token for a cookie, okay? The access token that we use to call the web API, in this example, was also a JSON web token, okay? But it could be something else, but that's a common scenario.
57:06
Okay, other questions? I hope somebody else had their hand up. Oh, okay. There's also, you said, supporting OAuth2 and everything.
57:24
How does it flow into doing authentication by Facebook or Google? Right, so if you do want to support identity providers, so actually let me go back here, log out, and log back in.
57:42
I am not logged out everywhere, am I? I'll do it quickly by just closing my app. So the whole point of this was identity server is going to become the abstraction for your app. Its job is to provide your app all the identity information
58:00
that your app needs. Identity server then can shield your app from wherever the user is really logging in from, like Google or a business partner or Azure or whatever. And so once we are on this login page, the way I've configured this particular demo is we only have the concept of local users, okay?
58:23
But like I said at the very beginning, identity server can work with other identity providers. And so identity server acts as sort of a middle man, if you will, or a gateway to those other providers. So you would configure identity server to then trust Google.
58:42
Just like we configured my MVC app to trust identity server, identity server can trust Google or Azure or some other product, okay? And so then on this screen then, we would then see options for click here to log in with Google or click here to log in with Facebook
59:01
or click here to log in with your corporate account, something like that. And so identity server then is doing all the brokering of the external provider information, right? And then just provides the one like sort of single facing or single view of the user to the application, okay?
59:20
Does that answer your... Okay. Yeah. So that's exactly the question is then so then once identity server has done some sort of handshake with some external provider, that external provider is giving a token to identity server. And then yes, identity server is in essence using that
59:42
to identify who it thinks the user is. And then it's issuing a new token back to your app. Would you store that in the database? Yeah, so would you store that in the database? The token is just temporary just to let you know...
01:00:00
the user is. What you usually do with that token is it has enough information so that you can identify who the user is, and you probably have a database of users, and that database knows, oh, this is my application's user or all of my application's user, but
01:00:21
he has an external provider from Facebook. And so Facebook is going to give you a unique ID for the user, and you use that to look up your user. So the token really is just conveying their identifier from Facebook. Sure, so it does contain an expiration. Well, so what's
01:00:51
happening is once we've authenticated the user, Identity Server issues its own authentication cookie. So now that's how single sign-on works. You're logged in at Identity Server.
01:01:00
You don't need to go back to Google, okay? And so you're in Identity Server for however long Identity Server's cookie is good for. Configurable, right? Make this however you want. And then as your apps come back to Identity Server, right, if you've gone to Facebook once, you then are logged in with Identity Server. Then all your other apps, though, they're going to come to Identity Server and then go back to your app. They
01:01:22
don't ever need to go back to Facebook. You've authenticated at that point. Does that make sense? Okay. Other questions? Okay. One more. So the question is do you have to host Identity Server separate to your Web API or even the MVC app? And so technically, no.
01:01:45
You could host them all together. But the best architectural use case is where you have multiple applications all trusting the single Identity Server. So you typically host it on its own, okay? Now, it could be hosted on the same IIS server, for example,
01:02:01
if you were hosting it there or in your same, you know, Azure subscription or, you know, however that stuff works, okay? Okay, great. So thank you so much. There are stickers up here, so feel free to decorate your laptops with stickers. And feel free to let us know how you think of Identity Server and if you have
01:02:21
questions. Thank you so much.