Defending PII Knowledge With JWT – DZone – Uplaza

The Problem

JWT tokens are extensively used for securing APIs by means of authentication and authorization. When an API request arrives, the useful resource server decodes and verifies the JWT token, usually validating the signature for authentication and checking claims or scopes for authorization. For instance, the server may use claims within the token to determine if the person can entry a specific endpoint.

Nevertheless, finer entry management is commonly wanted. As an example, when a request fetches a buyer’s checking account particulars, the server should make sure the person is accessing their very own account, not another person’s. 

A standard method is to incorporate the person’s account data within the JWT token claims or scopes, enabling the server to confirm the account being accessed. Whereas this works, it exposes Personally Identifiable Info (PII) like account numbers within the token. This publicity violates knowledge safety insurance policies, because the token could be publicly accessible if logged or copied from a browser, resulting in potential knowledge breaches.

Public Nature of a JWT Token

The content material of a JWT token’s payload will not be thought of secret or personal knowledge. JWT tokens usually have JSON Net Signature (Part 3 of RFC 7515), which is an encrypted string used to guard bits in a token from tampering. Because of this a JWT is signed moderately than encrypted. A JWT token gives safety by letting the useful resource server confirm the digital signature of the origin (IDP) thereby verifying that the token was not tempered or touched by some other entity. So far as JWT specification is worried, offering safety by Encryption shouldn’t be the intention (In all fashionable programs HTTP requests are secured utilizing HTTPS which takes care of encryption of your complete request together with that of the token). Subsequently the payload of a JWT token based mostly on JWS (JSON Net Signature) shouldn’t be alleged to include secrets and techniques or PII.

This is a fast refresher on the construction of a JWT token. A well-formed JWT token consists of three base64 encoded (not encrypted) strings, concatenated utilizing a dot (.) separator.

1. Header (Part 4 of RFC 7515): Accommodates metadata concerning the token together with the cryptographic algorithms used to safe its contents
2. JWT Payload: Accommodates a set of safety claims which can be verifiable by the useful resource server (a useful resource server hosts the API  or utility being protected) in a roundabout way that holds which means for the system being protected. These claims could be built-in claims outlined by the JWT specification or customized claims created and configured by the IDP (issuer of the token). See Part 4 of RFC 7519.
3. JWT Signature: Accommodates digital signature from IDP and is used to confirm that the token was not tampered with. Earlier than utilizing or storing a JWT token its signature should be verified.

Fixing the PII Downside in JWT

Given the problem we outlined above and the essential nature of a JWT token, allow us to contemplate a hypothetical instance and attempt to resolve it. Suppose a financial institution buyer is trying to fetch their checking account particulars, like account steadiness, transactions, and so on. Throughout the workflow, the applying calls a backend account API which is protected utilizing JWT tokens. Allow us to additionally assume that the JWT tokens are issued by an enterprise-level IDP like Auth0. The IDP is built-in with the group’s LDAP system for id federation and acts as an authoritative supply for managing person identities and entry. When a person authenticates, the request goes to the IDP that returns a JWT token in response. The JWT token consists of an identifier for the person, and a few built-in or customized claims describing the person’s entry. Now if we wish to present entry permissions to the granularity degree of a buyer’s account, a typical however flawed manner of attaining this is able to be to embed person’s accounts instantly within the token. 

Instance

This is an instance of the payload of such a token.

Base 64 Encoded Token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJzY29wZXMiOlsiYWNjb3VudHM6MTIzNDUsNDM3ODksOTA4NzUiXX0.r6bCsRn7ALxedEt8BZcqVc3YErCymtYHvSpPdsAnQaE

Decoded Token

Discover that the payload consists of account numbers instantly embedded into the token and facilitates comparability of the precise account from the present HTTPS request with these accounts from the token that the person is permitted to make use of. This method works so far as entry management is worried however places us in violation of PII privateness compliance as a result of the truth that a JWT token is publicly identifiable data (aside from the digital signature in fact) is ignored. In brief, the above token may find yourself introducing the next vulnerabilities in our system.

1. Publicity to delicate data: 
   • Embedding account numbers instantly exposes Personally Identifiable Info (PII). If the token is logged, intercepted, or in any other case uncovered (through browser for instance), delicate data could be accessed by unauthorized brokers.
   • JWT tokens even when signed, could be publicly decoded. So anybody can see the embedded PII knowledge.
2. Elevated danger of token misuse: 
   • Logging: Tokens is likely to be logged by shoppers, servers, or intermediate programs after decoding or earlier than encoding. Thus account numbers and different PII, if current within the token, could be inadvertently and unwittingly uncovered through logging.
   • Token Leakage: Typically throughout debugging and vendor help, tokens are exchanged for help tickets, and so on. account numbers and different PII knowledge can get uncovered unintentionally in such instances.
3. Regulatory compliance: 
   • Knowledge safety legal guidelines: Many jurisdictions and international locations have strict knowledge safety legal guidelines. Embedding PII knowledge in tokens may violate legal guidelines similar to GDPR or CCPA, resulting in potential authorized and monetary penalties.

Suggestions

To deal with the above vulnerabilities, we should comply with the beneath greatest practices. 

1. Use UUIDs or different non-PII identifiers as values of customized claims
   • As an alternative of embedding account numbers, use UUID or one other identifier that may be mapped to an precise account quantity from the database through the useful resource server internet hosting the protected API the person is attempting to invoke.
   • The fundamental precept is that when an account will get created in your transactional database it ought to get a UUID-like id assigned to it, which must also be synced into your IDP. The JWT token issued by the IDP then ought to include this id as an alternative of instantly embedding the account quantity.
2. Preserve the token payload to a minimal
   • You’ll at all times find yourself hitting dimension limits for the token payload as a result of it’s a part of the HTTP request. Subsequently, together with accounts or different application-specific particulars instantly within the token shouldn’t be solely insecure but additionally rigid. What’s going to you do if one in all your prospects is a company and has 1000’s of accounts (for departments and sub-departments) with the financial institution? It will drive you to incorporate a considerable amount of knowledge within the token thereby bloating the http request dimension.
3. Substitute direct embedding of delicate knowledge with server-side lookup
   • This advice extends the primary one above. If we comply with the essential precept that we are going to at all times embody an identifier (UUID or one thing comparable) as an alternative of precise knowledge and we be sure that this identifier is synced throughout the transactional database and IDP, then we are able to use this identifier to fetch the accounts from the database in the course of the token verification course of after the request arrives on the useful resource server. This permits us to carry out a comparability with the account(s) within the incoming request with the person’s account from the database and validate their entry permissions.
4. Think about using JWE (RFC 7516), if embedding delicate knowledge is totally obligatory
   • Whether it is unavoidable and completely obligatory to incorporate delicate data in JWT then we should always make use of JWE, to make sure that solely approved events are allowed to decrypt and entry the token payload. I imagine this must be the final resort as this introduces vital complexity and might also impression efficiency attributable to additional encryption/decryption logic.

Conclusion

Together with application-specific PII knowledge in JWT tokens to offer entry management at a finer degree of granularity works in precept however breaches PII knowledge safety and introduces the danger of violating Knowledge Safety Legal guidelines, similar to GDPR and CCPA. Utilizing Non-PII identifiers within the token payload and performing a server-side look-up of delicate knowledge utilizing these identifiers, as an alternative of direct token embedding can mitigate all these dangers and on the identical time present equal entry management capabilities to the specified high-quality degree of granularity.