OAuth2 falls into the token based authentication mechanism, which is different from session based authentication mechanism. By session based authentication mechanism, we mean an NTLM header or FedAuth cookie or similar, that must be passed to the Web server when you’re using a protected resource. Session based authentication is extremely limited, and is prone to CSRF attacks. Also the classic “remember me” functionality that everyone wants, requires us to store credentials on the client. Also protocols such as WS-Fed require web redirects that native clients have a problem handling, unless they host webviews.
Token based authentication, and therefore OAuth is different. OAuth requires you to get a token from an issuing authority. The Token typically a JWT (pronounced JOT) token is a JSON serialized token that contains various information such as validity of the token, digital signature, issuer information, and also, claims, to identify the user being authorized. With every single request this token, also known as an “access token” must be put in the “Authorization” header with a value of “Bearer <accesstoken>”. This approach is more secure and more flexible.
However there are two problems with this approach.
- The first problem is that if you get my access token, and you can party as me for the duration for the access token. The solution to that is https everything, and keep my access token’s duration as small as possible. Typical durations are no more than 30 minutes. The problem that this causes is that every 30 minutes the user must be asked for credentials again. We know users are not going to like that.
- The second problem with this approach is that once in access token has been issued, there is no way to revoke it from the server.
To solve both of these challenges we use a refresh token. A refresh token is issued along-with an access token. The difference is that a refresh token is much longer in duration, and it is also stored on the server in some persistent storage, such as SQL Server. This means, the refresh token can be revoked from the server at any time. This also means that the client must store the refresh token securely, and the client can request a new access token, 5 minutes before the access token is about to expire. The best thing is that the user doesn’t have to be prompted before the access token is renewed. So to the user it feels like an ongoing session.
With Azure AD, ADAL abstracts all of these details away from us. Now I still feel that in many instances you will need to manage tokens yourself. A common scenario is enterprise mobile apps where wish to encrypt these refresh tokens with a key that is being issued to you by the mobile applications administrator. Luckily ADAL has enough hooks to let us access the refresh token if need be.
So now you know OAuth2 in a very simple manner! No heavy duty language here.