Thursday, March 1, 2018

I saw Jeff St. Germain and Kevin Grossnicklaus speak on making Angular 5 applications secure at the STL Angular Meetup at Bullhorn last night.

OpenID Connect is a protocol for tokens on top of OAuth 2.0 which allows for identification and authorization from a client elsewhere (a JavaScript app that cannot be secured in and of itself as all code just lives at the browser) that is sometimes abbreviated at just: oidc ...Jeff (seated) and Kevin (standing) use a technology called Identity Server (specifically Identity Server 4) to empower such identity management in lieu of using other openesque, out-in-the-world technologies such as the login for Facebook, Twitter, or gmail to do as much. (With the other three one creates an app at their store and then logs in against it.) JetBrains Rider is a cross-platform IDE that one may use for .NET and C# too and Jeff and Kevin use it to edit C# at their Identity Server implementation and work on Macintoshes. Yes, Identity Server is of .NET Core! It is free open source software and there is a GitHub project for it somewhere, and, you guessed it, it uses oidc too. Specifically, it passes JWT (pronounced "Jot") tokens from the client to an API server to Identity Server running elsewhere and then back again. An API server offering up REST endpoints to the client (an Angular 5 application) is consistently the middleman managing crosstalk between the Identity Server and Angular 5 while also largely passing communications through. Identity Server has a concept of "scopes" which are URLs allowed as sources for requests. Sources of communication outside of the scopes get an applicable denial message and this is a friendlier user experience than just blocking outsiders without an explanation by way of CORS so CORS is just left open at the API server and also left open at the Identity Server where it too could be configured in favor of just letting the scopes do the safeguarding one might normally associate with CORS. When one first logs in one is given both an authentication token and an identity token. The identity token acts as a bearer token affirming your login credentials and that you may at least log in. The authentication token is not refreshed, but the bearer token is sent back to the server every five hundred seconds where it is affirmed (or rejected) and then, if affirmed, sent back to the client to replace the now no longer current old token. One may log in, leave the browser untouched for a day, and still be logged in when they return to the browser after being bailed out of jail for a DUI in this shape of things. The authentication token may be consumed as an any type in TypeScript (Jeff and Kevin do this) and therein there will be a .role hanging off of it which is an array of strings. This is used for "claims" which is a grocery list of details about who the user is. My name is Tom. I am an administrator. And so on... The claims may be used to drive things at the UI like whether or not the History Eraser Button from Ren & Stimpy shows up to begin with, but if, as an administrator, I click the History Eraser Button and I send a request back to the API server and then the Identity Server does not actually deem that I'm an administrator it could deny my request. As the authentication token is not getting recreated until I log out and log back in again, how will I be forbidden from doing things I should not be doing when I am spending the day in jail with a DUI and my boss downgrades my permissions at the server while I am away? Well, the requests to the server coming from REST calls will be blocked even if the UI still shows the History Eraser Button, right? Don't stress too hard about permissions at the client. At worst, permission woes therein make for a bad user experience. At the API server or Identity Server however and in contrast lax security can... well, you don't need a speech from me. Sanity check every request coming across the wire. Trust nothing. Another interesting thing to come up in this talk was NSwag, a tool for consuming the Swagger notes for an API and auto-generating the boilerplate code for a service for an Angular 5 app to talk to the API in TypeScript. Jeff and Kevin use this. They have an HttpInterceptor in their Angular 5 frontend to inject JWT tokens into every REST call rather than doctoring up generated code by hand which would be ghetto and hard to maintain.

No comments:

Post a Comment