Token-Based Security?
ØToken-based security means that in order for us to prove that we have access, we first have to retrieve a token.
ØIn a real-life scenario, a token could be an access card to a building, it could be the key to the lock to your house. In order for you to retrieve a key card for your office or the key to your home, you first need to prove who you are and what you, in fact, do have access to that token.
Exchanging Credentials for a Token
Why Token Security
ØI want you to keep that in mind, treat your tokens like passwords, but you can also have the expiry in mind.
ØHow do we keep one of these tokens secure? Imagine in this case here, we are doing a request to our API with our token. The token is sent in the header whenever we are doing a request to our API, and the API then just returns some data.
ØWhat happens if someone looks at our token and inspects that as we are doing our call to our API? Looking at the token is probably not as bad as if they started changing it. So how do we make sure that our token is in fact not changed?
ØWell it's up to the API to make sure that no one tampered with the token, but how do we do that? You know, if we provided our username and password, there would be no way for us to know if the man in the middle stole our username and password.
ØThe API wouldn't know if they tampered with the username or password, but in this case here, we are providing something called a token, and in token-based security scenarios, what happens is that the token is in fact signed, which makes sure that the data isn't tampered with.
What is a Token
1. JSON web token
2. Signed by the authorization server
I. The private key for signature lives only on the authorization server
II. Public key available for token validation
III. Contains information about the authorization server
3. Referred to as access token or identity token
4. Base64 encoded
Token types
Øaccess tokens
Ørefresh tokens
Access tokens
ØAccess tokens
carry the necessary information to access a resource directly. In other words, when a client passes an access token to a server managing a resource, that server can use the information contained in the token to decide whether the client is authorized or not. Access tokens usually have an expiration date and are short-lived.
resource server
The resource server is the OAuth 2.0 term for your API server. The resource server handles authenticated requests after the application has obtained an access token.
Refresh tokens
Øcarry the information necessary to get a new access token. In other words, whenever an access token is required to access a specific resource, a client may use a refresh token to get a new access token issued by the authentication server.
ØThe refresh token normally is sent together with the access token.
ØThe refresh token is used to get a new access token when the old one expires. Instead of the normal grant type, the client provides the refresh token and receives a new access token.
ØWe can get a new access token without client credential use of this refresh token.
OAuth and OpenId Connect
OAuth and OpenID Connect are simply protocols to allow us to build more secure applications. Simply put, these protocols tell us how we need to build our APIs, and how third parties and ourselves can access our API and retrieve access to the APIs in a common and secure manner.
OAuth - Authorization(access)
1. An open standard for authorization
2. Token-based
I. Access token
II. JSON web token(JWT)
3. OAuth 2.0
I. Simple
II. Not backward compatible
Open id-Authentication(identity)
ØSo OAuth only stands for the authorization part, so how do we get the identity part? That's where OpenID Connect comes into the picture. It complements OAuth 2. 0 with authentication.
ØSo OpenID Connect, it's a simple identity layer on top of OAuth 2. 0, which allows the client to verify the identity of the end-user based on the authentication performed by the authorization server.
ØThat means that we can then extract basic information such as their profile information. So we can get more information about the end-user by using OpenID Connect.
ØSo it will allow us to identify who the user is after we know that they have access.
Identity server
ØIdentityServer is built by security experts that know all there is to know about OAuth and OpenID Connect.
ØThey've implemented these protocols in this product called IdentityServer, which is a free product to use and it's open-source.
ØBy using this framework in our ASP. NET Core application, we'll make it both easier for us to implement both OAuth and OpenID Connect, and we can trust that our API is going to be a lot more secure than if we rolled our own implementation.
The RFC and Useful Endpoints
/token
Øwe also has a token endpoint, and just as the authorization endpoint, this endpoint also allows us to perform a new access token request.
ØBut this endpoint also allows us to refresh our access token. So in certain flows, what we are allowed to do is that we are allowed to refresh our access token.
Ø So normally what happens is that you provide your username and password, and you get this token that proves that you are authorized to access the API.
/revocation
ØWe also has an endpoint that allows us to revoke access tokens; however, this is an extension to the OAuth 2. 0 authorization framework specification, but it's implemented by IdentityServer.
ØThis allows us to revoke both an access and a refresh token. So that's pretty much it.
OAuth Roles
ØResource Owner
ØClient
ØResource Server
ØAuthorization Server
Resource Owner: User
The resource owner is the user who authorizes an application to access their account. The application’s access to the user’s account is limited to the “scope” of the authorization granted (e.g. read or write access).
Resource / Authorization Server: API
ØThe resource server hosts the protected user accounts, and the authorization server verifies the identity of the user then issues access tokens to the application.
ØFrom an application developer’s point of view, a service’s API fulfills both the resource and authorization server roles. We will refer to both of these roles combined, as the Service or API role.
Client: Application
The client is the application that wants to access the user’s account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.
Abstract Protocol Flow
Application Registration
Before using OAuth with your application, you must register your application with the service. This is done through a registration form in the “developer” or “API” portion of the service’s website, where you will provide the following information (and probably details about your application):
ØApplication Name
ØApplication Website
ØRedirect URI or Callback URL
The redirect URI is where the service will redirect the user after they authorize (or deny) your application, and therefore the part of your application that will handle authorization codes or access tokens.
Client ID and Client Secret
ØOnce your application is registered, the service will issue “client credentials” in the form of a client identifier and a client secret.
ØThe Client ID is a publicly exposed string that is used by the service API to identify the application and is also used to build authorization URLs that are presented to users.
ØThe Client Secret is used to authenticate the identity of the application to the service API when the application requests to access a user’s account and must be kept private between the application and the API.
Grant types
ØIn OAuth 2.0, the term “grant type” refers to the way an application gets an access token. OAuth 2.0 defines several grant types, including the authorization code flow. OAuth 2.0 extensions can also define new grant types.
ØEach grant type is optimized for a particular use case, whether that’s a web app, a native app, a device without the ability to launch a web browser or server-to-server applications.
ØAuthorization Code
ØImplicit
ØResource Owner Password Credentials
ØClient Credentials
No comments:
Post a Comment