fbpx
wave-1 wave-2

There is no entry without permission – user authentication and authorization

There is no entry without permission – user authentication and authorization
Autor: Szymon Wasiak
Share:

There are two basic types of tokens:

  • ?access tokens?
  • ?ID tokens?.

The identification token is JSON Web Tokens (JWTs), which should only be used by applications.

For example, a fictional application using account authentication with a ready-made Google account. Google sends an identification token to the application, which contains information about the user. The application analyzes data from the token and then uses important information such as: name, surname, address, photo.

“ID Tokens” should not be used to access APIs.

According to OpenID Connect, the recipient of an ID token must be the client from the application ID sending the authentication request. If this condition is not met, the token cannot be trusted.

This mechanism also works the other way around, the API expects a token with a specified aud value, which is equal to the unique API ID.

Access tokens are used to:

  • inform the API that the user providing the token has been authorized to access the API
  • to carry out a pre-determined set of actions (determined by the allocated scopes).

Access tokens cannot be used for authentication and cannot determine whether the user has obtained them. It does not contain any personal user data. The only information the access token stores is an identifier.

Applications should not treat access tokens as opaque Strings. They should not attempt to declare them or expect to receive tokens in the correct format.

JSON Web token is an open standard RFC 7519 that defines how the JSON object can securely exchange data between pages.

The information contained in the token is electronically signed, making it trustworthy. The JWT can be signed with a secret key (on the HMAC algorithm) or public/private pairs (RSA or ECDSA).

JSON Web Token can be used during authorization when one of the parties wants to grant access to services and resources, and without storing the status, wants to verify whether access should be granted.

JWT as an access token can also be used for data transmission or information exchange. Thanks to the signatures of public/private key pairs, you can be sure that the broadcasters are who they claim to be. The signature is calculated by using the header and load. You can also check if the content has been changed.

The structure of the JWT is as follows: xxx.yyyy.zzz

  • The header usually consists of two parts: information about the type of token or JWT and the algorithm we use, i.e. HS256, RSA or HS512. Then the body of the following JSON is coded in Base64Url and creates first part of JWT.
    {
  alg??: ??HS256?
  ?typ?: ??JWT??
}
  • The content of PayloadJWT token is responsible for storing the data we intend to send in the token. Moreover, the token contains types of information such as: Registered claims, Public claims, Private claims. In addition to information about the expiry date, identification data and user rights. It is coded in Base64 format.
    {
  alg??: ??HS256?
  ?typ?: ??JWT??
}
  • The digital signature (Verifay) confirms the authenticity of the data, giving certainty that the sender is who he claims to be. By selecting the HMAC algorithm SHA256 will be created in the following way: HMACSHA256(base64UrlEncode(header) + ‘. + base64UrlEncode(payload), secret). Note that the secret (password) should be of considerable length and contain different characters.

JASON Web Tokens can be used to build an authorization service where we can authenticate users of the application. The token that goes to the server is parsed and then verified for correctness, permissions, validity, TTL and others.

OAuth 2.0 is an open protocol that allows to create authorization mechanisms using various platforms such as mobile, web and classic applications. In the process of obtaining a token, the client, resource owner and authorization server will take part.

A resource owner is an entity that can grant access to a protected resource. It is usually an end user.

A client is an application requesting access to a protected resource on behalf of the resource owner.

An authorization server is a server that authenticates the owner of the resource and issues access tokens after obtaining the appropriate authorization. In this case Auth0.

Access tokens must be confidential during transport and storage. The only pages that should see the access token are the application itself, the resource server and the authorization server. The access token can only be used by https protocols, as passing it through an unencrypted channel could lead to easy interception by unauthorized persons.

The benefits of using are measurable. Customers, i.e. external applications, have no contact with user authentication data. It is possible to use one authorization server to protect several different resources. It also allows to limit the number of accounts set up in different applications and thus eliminates the risk of using the same password in different applications.

The method of obtaining a token must be adapted to its needs. If the customer is run through the web we should use the Implicit Grant method (customer created using JavaScript). When we know that the client comes from a trusted source and is e.g. a business partner, we can use Client credentials flow (only the ID and secret are sent to the authorization server).

The most likely scenario is that the client is an untrusted application, while one of the elements of the process is the owner in an open form using a web browser. Here the Authorization Code Flowe method should be used.

The threats resulting from the use of OAuth 2.0 include the lack of an encrypted communication channel. Compared to OAuth 1.0, communication channel encryption has been completely withdrawn, so TLS encryption is crucial. Leakage is tantamount to the use of token by unauthorized persons. The client is an element of the system and it has certain privileges that are given by the generated token. The client is entrusted with the task of storing the token in an appropriate way, both in case of classic attacks and during the occurrence of an error in the application and an error message related to it. This concerns both the token and the refreshing token. It is also dangerous to store tokens in browser cookies, which are vulnerable to Cross-Site Scription and Cross- Site Reguest Forgery attacks.

Compared to version 1.0, there have been major changes in terms of convenience in various business scenarios. The huge disadvantage is the removal of standards and encryption mechanisms. This may cause various controversies concerning security guaranteed by OAuth 2.0 token.

Bibliography:

Autor: Szymon Wasiak, Test Automatyzujący