https://github.com/ayushkhodankar/springboot-jwttokens
Basic use of JWT Tokens in Spring-Boot Microservices
https://github.com/ayushkhodankar/springboot-jwttokens
java jwt-authentication jwt-token microservices spring-boot sts
Last synced: about 1 month ago
JSON representation
Basic use of JWT Tokens in Spring-Boot Microservices
- Host: GitHub
- URL: https://github.com/ayushkhodankar/springboot-jwttokens
- Owner: Ayushkhodankar
- Created: 2023-01-30T14:44:55.000Z (about 2 years ago)
- Default Branch: master
- Last Pushed: 2024-09-09T03:42:09.000Z (8 months ago)
- Last Synced: 2025-01-23T06:32:03.097Z (3 months ago)
- Topics: java, jwt-authentication, jwt-token, microservices, spring-boot, sts
- Language: Java
- Homepage:
- Size: 41 KB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# SpringBoot-JWT Tokens
What is a JSON Web Token?
JSON Web Token (JWT) is a _general-purpose_ text-based messaging format for transmitting information in a
compact and secure way. Contrary to popular belief, JWT is not just useful for sending and receiving identity tokens
on the web - even if that is the most common use case. JWTs can be used as messages for _any_ type of data.
A JWT in its simplest form contains two parts:
. The primary data within the JWT, called the `payload`, and
. A JSON `Object` with name/value pairs that represent metadata about the `payload` and the
message itself, called the `header`.
A JWT `payload` can be absolutely anything at all - anything that can be represented as a byte array, such as Strings,
images, documents, etc.
But because a JWT `header` is a JSON `Object`, it would make sense that a JWT `payload` could also be a JSON
`Object` as well. In many cases, developers like the `payload` to be JSON that
represents data about a user or computer or similar identity concept. When used this way, the `payload` is called a
JSON `Claims` object, and each name/value pair within that object is called a `claim` - each piece of information
within 'claims' something about an identity.
And while it is useful to 'claim' something about an identity, really anyone can do that. What's important is that you
_trust_ the claims by verifying they come from a person or computer you trust.
A nice feature of JWTs is that they can be secured in various ways. A JWT can be cryptographically signed (making it
what we call a https://tools.ietf.org/html/rfc7515[JWS]) or encrypted (making it a
https://tools.ietf.org/html/rfc7516[JWE]). This adds a powerful layer of verifiability to the JWT - a
JWS or JWE recipient can have a high degree of confidence it comes from someone they trust
by verifying a signature or decrypting it. It is this feature of verifiability that makes JWT a good choice
for sending and receiving secure information, like identity claims.
Finally, JSON with whitespace for human readability is nice, but it doesn't make for a very efficient message
format. Therefore, JWTs can be _compacted_ (and even compressed) to a minimal representation - basically
Base64URL-encoded strings - so they can be transmitted around the web more efficiently, such as in HTTP headers or URLs.