This is based on an email I send my .NET team at work
Happy holiday weekend,
This week I’ve been digging into Identity Server and wanted to brain dump some of what I’ve been learning, as well as helpful resources that I found.
Identity Server is a framework for building authentication and authorization features in .NET applications. It seems like every couple years there’s a new auth library for ASP.NET, but I think this one is going to be around for awhile. It’s actively maintained, the authors are very responsive and helpful, and it seems to have excellent extensibility points.
More of our projects are becoming distributed between a front-end application server and set of back-end API services, and thus we need to share authentication and authorization throughout the system. Identity Server provides this feature through tokens. When the user logs in, they get a token that contains some identity information and other details about who they are and what they can access. This token can then be passed through the system. Each API server doesn’t have to do another explicit authorization check: the token tells them everything they need to know.
Well couldn’t somebody just tamper with the token and change their
role attribute to
superuser or change their user id to impersonate
some other user?
No, the token is signed by Identity Server, and thus tampering with the token would make the signature check fail, and the token would be rejected by the any of the API layers.
This page gives an overview of many of the domain concepts you’ll see frequently when working with Identity Server.
A couple that are important to know are Scopes and Claims.
Scopes are just names for resources a client (software program) wants to access. Some scopes are resource scopes, like “the calendar API” and some are bits of user information, like “profile”.
Users have control over what Scopes they allow a client to access on their behalf. For example, if you’ve ever signed into a website using your Google account, it probably asked for access to read your email address and name. Or if you installed a third-party twitter app, it asked for permission to access your timeline, your DMs, and your profile information. Each of those are Scopes. Users have a chance to review what the client is going to access and make informed consent.
Scopes often involve a set of Claims. Claims are a key-value storage
of bits of information, usually about the current user. You might have a
role:admin. A user can have multiple
of the same claim type, for example one could have more than one role in
You can use the claims about a user to retrieve additional information or to control what pieces of information they can access.
If you want to learn more, I’d recommend doing these two tutorials in order. They are very helpful for learning how all the pieces fit together. I generally recommend that you type in all the code rather than copy-pasting. I’ve found that it sticks in my brain better when I do that, because it forces me to slow down and see how the pieces connect.
In Identity Server, a lot of things are connected together by names given
string literals. So take note when you find yourself typing the same
string value in two places: there’s probably a connection there.
Also check out the main documentation. There’s a ton of other things that Identity Server can do, and it has extension points to fit it into any client’s authentication needs.