![\"Flowchart](\"/f29edbf2978577390c7ffa02e9bc4dda/lr-JWT-authentication.webp\")
Ever wondered how apps like Spotify, Netflix, or Slack manage seamless login experiences across devices? Many of them use JWT, or JSON Web Tokens, a compact, stateless method for securely transmitting user identity and session data across services.
\nWith JWT token authentication, identity information is embedded in a signed token, allowing you to maintain user sessions without server-side storage. This approach is highly scalable and ideal for modern architectures like SPAs, mobile apps, and microservices.
\nIn this blog, we’ll walk you through what is JWT, why use it, and how to implement JWT authentication using LoginRadius.
\nYou’ll learn what JWT is, why it’s effective, and how it works in real-world applications. We'll cover both integration methods (IDX and Direct API), generating your signing key, managing sessions, storing the JWT token securely, and applying best practices throughout.
\nWhether you're a developer, product manager, or IAM architect, this guide offers a complete foundation for implementing JWT token authentication into your application stack.
\nJSON Web Token (JWT) is an open standard (RFC 7519) used to transmit information securely between parties as a JSON object. It’s compact, self-contained, and digitally signed, making it a reliable format for authentication and authorization across modern applications.
\nA JWT consists of three parts:
\nExample of a token structure:
\n<base64Header>.<base64Payload>.<signature>
\n
JWT simplifies identity verification, especially when you're building apps that talk to APIs or need to scale without centralized session storage.
\nLoginRadius provides robust support for JWT (JSON Web Token) authentication, which allows for flexible and secure access control across different digital platforms. Whether you're building a fully custom identity flow or using a pre-built interface, the platform supports various integration approaches depending on your architecture.
\nIf you're looking to understand how to implement JWT token authentication effectively, LoginRadius offers two primary implementation models that cater to different levels of customization and control:
\nThe IDX-hosted login approach enables secure, standards-compliant, JWT-based authentication without requiring you to build a custom login interface. This is a strategic option for fast, compliant, and user-friendly deployments.
\n![\"Screenshot](\"/9fb19dd9c88c7916aeebd03ab6e661b7/lr-admin-console.webp\")
{
\n\"access_token\": \"eyJhbGciOiJIUzI1NiIsInR...\",
\n\"expires_in\": 1800
\n}
\nThis integration approach works best for all teams that want effective identity workflows without the complexity of building proprietary login screens, something that is crucial for customer portals, onboarding of mobile applications, and even managing access for business partners.
\nIf you’re building a custom login UI or working in a headless environment, LoginRadius lets you generate and handle JWTs directly through its Authentication APIs. Here’s how you can programmatically perform token authentication using the classic method:
\nSend a POST login request to the LR Authentication URL:
\nPOST /identity/v2/auth/login
\nInclude the user’s credentials (email + password) in the request body.
\n{
\n\"access_token\": \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...\",
\n\"expires_in\": 3600
\n}
\nWith LoginRadius, it is possible to customize the payload to include user roles and/or any additional metadata. You can set custom JWT claims on the Admin Console.
\nWith this method, you have complete customization over login flows while using LoginRadius to issue signed JWTs for user session management.
\nNOTE- With either method, LoginRadius ensures that JWTs are securely signed, optionally short-lived, and compatible with standard token validation libraries, making integration seamless for everyone.
\nTo get started with JWT implementation, you can read our complete developer documentation.
\n![\"Illustration](\"/15ec02ac98d24a9f1f28e5d0f06b9174/IDX-vs-Direct-API-JWT.webp\")
Session management is how your app keeps track of a user after they log in so they don’t have to prove who they are with every request.
\nIn traditional apps, sessions are stored on the server using session IDs. Every time a request comes in, the server checks that session ID to verify the user.
\nIn modern apps, especially SPAs and APIs, JWTs are used to manage sessions without needing server-side storage; this is called stateless session management. The token itself carries the user’s identity, roles, and expiration details. As long as the token is valid, the user stays logged in.
\nGood session management ensures:
\nUser Logs In
\nClient Stores the Token
\nAccess Token Expiry
\nToken Renewal
\nWhen the user logs out, both the access token and refresh token should be cleared from client storage.
\nHowever, access tokens are stateless and cannot be revoked mid-lifecycle unless:
\nCombining these strategies gives you greater control over token misuse and enables a robust, enterprise-grade logout flow.
\n![\"illustration](\"/e55ae4bbc8ce62e13f03e46e29ebe7cc/api-economy.webp\")
When you implement JWT-based authentication, the client (browser or mobile app) needs a way to store the access token and, optionally, the refresh token after they are issued by the authentication server. This stored token is then attached to every subsequent request to prove the user's identity.
\nChoosing where to store the JWT is a crucial security decision. The most common storage options are:
\nEach option has trade-offs between security, accessibility, and persistence, and the right choice depends on your application's architecture and threat model.
\nAccess Tokens
\nRefresh Tokens
\nJWT authentication with LoginRadius offers a modern, stateless approach to managing sessions across distributed systems. The IDX integration is ideal for rapid deployment, while the Direct API model is best for organizations needing deep customization and integration flexibility.
\nWith robust token signing, refresh capabilities, and centralized control, LoginRadius provides a future-ready foundation for secure, scalable identity architecture. Contact us to know more about JWT authentication and implementation guide.
\nA: JWT authentication securely verifies user identities, enabling stateless session management across web, mobile apps, and microservices without server-side session storage.
\nA: LoginRadius simplifies JWT integration by offering hosted IDX login pages and direct API-based authentication methods, enabling rapid deployment and deep customization.
\nA: Yes, JWT authentication is secure when implemented with best practices like short-lived tokens, secure storage methods, signature validation, and refresh token rotation.
\nA: Yes, LoginRadius allows revocation of JWT refresh tokens explicitly, and supports strategies like short-lived tokens and key rotation to manage token lifecycles securely.
\n","frontmatter":{"date":"April 15, 2025","updated_date":null,"title":"JWT Authentication with LoginRadius: Quick Integration Guide","tags":["JWT","JSON Web Token","Authentication","Authorization"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":0.7782101167315175,"src":"/static/4cedb7829f98208cbc6d5a9aea4e983d/58556/how-to-integrate-jwt.webp","srcSet":"/static/4cedb7829f98208cbc6d5a9aea4e983d/61e93/how-to-integrate-jwt.webp 200w,\n/static/4cedb7829f98208cbc6d5a9aea4e983d/1f5c5/how-to-integrate-jwt.webp 400w,\n/static/4cedb7829f98208cbc6d5a9aea4e983d/58556/how-to-integrate-jwt.webp 800w,\n/static/4cedb7829f98208cbc6d5a9aea4e983d/1cc9f/how-to-integrate-jwt.webp 896w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Kundan Singh","github":null,"avatar":null}}}},{"node":{"fields":{"slug":"/engineering/jwt-authentication-with-deno/"},"html":"In this blog, we’ll see how to create and validate a JWT(JSON Web Token) in Deno. For this, we’ll be using djwt, the absolute minimum library to make JSON Web Tokens in deno and Oak framework
\nThis tutorial assumes you have:
\nJSON Web Token is an internet standard used to create tokens for an application. These tokens hold JSON data and are cryptographically signed.
\nHere is how a sample Json Web Token looks like
\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6Im9sYXR1bmRlZ2FydWJhQGdtYWlsLmNvbSIsImJWT is a good way of securely sending information between parties. Because JWTs can be signed—for, you can be sure the senders are who they say they are. And, as the signature is generated using the header and the payload, you can also verify that the content hasn't been tampered with.
\nJWT can contain user information in the payload and also can be used in the session to authenticate the user.
\nIf you want to know more about JSON Web Token, We have a very good article about it.
\nFirst, let's set up a Deno server to accept requests, for it, we are using Oak framework, it is quite simple and few lines of codes as you can see below.
\n// index.ts\nimport { Application, Router } from "https://deno.land/x/oak/mod.ts";\n\nconst router = new Router();\nrouter\n .get("/", (context) => {\n context.response.body = "JWT Example!";\n })\n\nconst app = new Application();\napp.use(router.routes());\napp.use(router.allowedMethods());\n\nawait app.listen({ port: 8000 });Once our program is ready for accepting request Let's import djwt functions to generate JWT token, In below code we can use a secret key, expiry time for JWT token in 1 hour from the time program will run and we are using HS256 algorithm.
\nAdd the below code in index.ts and update the router as shown below, you can now get a brand new token on http://localhost:8000/generate
// index.ts\n...\n\nimport { makeJwt, setExpiration, Jose, Payload } from "https://deno.land/x/djwt/create.ts";\n\nconst key = "secret-key";\nconst payload: Payload = {\n iss: "Jon Doe",\n exp: setExpiration(new Date().getTime() + 60000),\n};\nconst header: Jose = {\n alg: "HS256",\n typ: "JWT",\n};\n\n\nconst router = new Router();\nrouter\n .get("/", (context) => {\n context.response.body = "JWT Example!";\n })\n .get("/generate", (context) => {\n context.response.body = makeJwt({ header, payload, key }) + "\\n";\n })\n\n...Once you get a JWT token you can validate the token by validateJwt function in djwt, let us import the validateJwt and add one more route /validate/:token
Now you can verify any token by passing it to a route like - http://localhost:8000/validate/jwt_token (jwt_token is a placeholder, please replace it with a real JWT token)
// index.ts\n...\n\nimport { validateJwt } from "https://deno.land/x/djwt/validate.ts";\n\n...\n\nrouter\n .get("/", (context) => {\n context.response.body = "JWT Example!";\n })\n .get("/generate", (context) => {\n context.response.body = makeJwt({ header, payload, key }) + "\\n";\n })\n .get("/validate/:token", async (context) => {\n if ( context.params && context.params.token && (await validateJwt(context.params.token, key)).isValid) {\n context.response.body = "Valid JWT\\n";\n } else {\n context.response.body = "Invalid JWT\\n";\n }\n });\n\n...Now you know how to generate and verify a JWT token in Deno, you can easily use it in your application, The complete source code used in this blog can be found in this Github Repo
\n","frontmatter":{"date":"July 10, 2020","updated_date":null,"title":"How to create and validate JSON Web Tokens in Deno","tags":["Deno","JWT","JSON Web Token"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.492537313432836,"src":"/static/2ca148ad6e08643634262607131d918e/58556/deno_jwt.webp","srcSet":"/static/2ca148ad6e08643634262607131d918e/61e93/deno_jwt.webp 200w,\n/static/2ca148ad6e08643634262607131d918e/1f5c5/deno_jwt.webp 400w,\n/static/2ca148ad6e08643634262607131d918e/58556/deno_jwt.webp 800w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Puneet Singh","github":"puneetsingh24","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/nodejs-and-mongodb-application-authentication-by-jwt/"},"html":"In this blog, we’ll be implementing authentication with JWT in a NodeJS web application. For this, we’ll be using jsonwebtoken package
\nJWT(JSON Web Token) is a token format. It is digitally-signed, self-contained, and compact. It provides a convenient mechanism for transferring data. JWT is not inherently secure, but the use of JWT can ensure the authenticity of the message so long as the signature is verified and the integrity of the payload can be guaranteed. JWT is often used for stateless authentication in simple use cases involving non-complex systems.
\nHere's an example of JWT:
\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6Im9sYXR1bmRlZ2FydWJhQGdtYWlsLmNvbSIsImNow, let's authenticate/protect some routes.
\nPre-requisites:
\nyou can install all required packages by using following command:
\nnpm install express mongoose bcrypt --saveStep 1. First, create a directory structure as below :
\nJWTApp
-api\n--models\n----userModel.js\n--controllers\n----userController.js\n--route\n----userRoute.js\n--server.js npm install jsonwebtoken -- saveIn the api/models folder, create a file called user userModel.js by running touch api/models/userModel.js.
\nIn this file, create a mongoose schema with the following properties:
\nAdd the following code
\n'use strict';\n\nvar mongoose = require('mongoose'),\n bcrypt = require('bcrypt'),\n Schema = mongoose.Schema;\n\n/**\n * User Schema\n */\nvar UserSchema = new Schema({\n fullName: {\n type: String,\n trim: true,\n required: true\n },\n email: {\n type: String,\n unique: true,\n lowercase: true,\n trim: true,\n required: true\n },\n hash_password: {\n type: String\n },\n created: {\n type: Date,\n default: Date.now\n }\n});\n\nUserSchema.methods.comparePassword = function(password) {\n return bcrypt.compareSync(password, this.hash_password);\n};\n\nmongoose.model('User', UserSchema);In the api/controllers folder, create a file called user userController.js by running touch api/controllers/userController.js
\nIn the userController file, create three different handlers to handle by using the following code
\n'use strict';\n\nvar mongoose = require('mongoose'),\n jwt = require('jsonwebtoken'),\n bcrypt = require('bcrypt'),\n User = mongoose.model('User');\n\nexports.register = function(req, res) {\n var newUser = new User(req.body);\n newUser.hash_password = bcrypt.hashSync(req.body.password, 10);\n newUser.save(function(err, user) {\n if (err) {\n return res.status(400).send({\n message: err\n });\n } else {\n user.hash_password = undefined;\n return res.json(user);\n }\n });\n};\n\nexports.sign_in = function(req, res) {\n User.findOne({\n email: req.body.email\n }, function(err, user) {\n if (err) throw err;\n if (!user || !user.comparePassword(req.body.password)) {\n return res.status(401).json({ message: 'Authentication failed. Invalid user or password.' });\n }\n return res.json({ token: jwt.sign({ email: user.email, fullName: user.fullName, _id: user._id }, 'RESTFULAPIs') });\n });\n};\n\nexports.loginRequired = function(req, res, next) {\n if (req.user) {\n next();\n } else {\n\n return res.status(401).json({ message: 'Unauthorized user!!' });\n }\n};\nexports.profile = function(req, res, next) {\n if (req.user) {\n res.send(req.user);\n next();\n } \n else {\n return res.status(401).json({ message: 'Invalid token' });\n }\n};Note: A hash password was saved in the database using bcrypt.
\nStep 6. In the api/route folder, create a file called user userRoute.js and add the following code:
\n'use strict';\nmodule.exports = function(app) {\n var userHandlers = require('../controllers/userController.js');\n // todoList Routes\n app.route('/tasks')\n .post(userHandlers.loginRequired, userHandlers.profile);\n app.route('/auth/register')\n .post(userHandlers.register);\n app.route('/auth/sign_in')\n .post(userHandlers.sign_in);\n};'use strict';\n\nvar express = require('express'),\n app = express(),\n port = process.env.PORT || 3000,\n\n\n User = require('./api/models/userModel'),\n bodyParser = require('body-parser'),\n jsonwebtoken = require("jsonwebtoken");\n\nconst mongoose = require('mongoose');\nconst option = {\n socketTimeoutMS: 30000,\n keepAlive: true,\n reconnectTries: 30000\n};\n\nconst mongoURI = process.env.MONGODB_URI;\nmongoose.connect('mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb', option).then(function(){\n //connected successfully\n}, function(err) {\n //err handle\n});\n\napp.use(bodyParser.urlencoded({ extended: true }));\napp.use(bodyParser.json());\n\napp.use(function(req, res, next) {\n if (req.headers && req.headers.authorization && req.headers.authorization.split(' ')[0] === 'JWT') {\n jsonwebtoken.verify(req.headers.authorization.split(' ')[1], 'RESTFULAPIs', function(err, decode) {\n if (err) req.user = undefined;\n req.user = decode;\n next();\n });\n } else {\n req.user = undefined;\n next();\n }\n});\nvar routes = require('./api/routes/userRoutes');\nroutes(app);\n\napp.use(function(req, res) {\n res.status(404).send({ url: req.originalUrl + ' not found' })\n});\n\napp.listen(port);\n\nconsole.log(' RESTful API server started on: ' + port);\n\nmodule.exports = app;Step 9. Now you just need to run the project by using the following command and try logging by using the JWT.
\nnpm startStep 10. Open Postman and create a post request to localhost:3000/auth/register as below:
\n![\"Postman](\"/a6eec58240d18cb17146ca11b5d49dcd/register.webp\")
Step 11. After this, let’s sign with this URL localhost:3000/auth/sign_in . Enter the keys and values for email and password
\n![\"Postman](\"/5cb1b965f14b8f3b4d254d7d310c789d/signIn.webp\")
Under the value, add JWT and the token with a space between, like so:
\nJWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6Im9sYXR1bmRlZ2FydWJhQGdtYWlsLmNvbSIsImZ1bGxOYW1lIjoiT2xhdHVuZGUgR2FydWJhIiwiX2lkIjoiNThmMjYzNDdiMTY1YzUxODM1NDMxYTNkIiwiaWF0IjoxNDkyMjgwMTk4fQ.VcMpybz08cB5PsrMSr25En4_EwCGWZVFgciO4M-3ENEStep 11. Then, enter the parameters for the key and value for fetching the profile. You want to create as shown below and send:
\n![\"Postman](\"/42b50f8f60ca459023e492ce1b802845/profile.webp\")
As we have seen it is fairly easy to build a JWT authentication system with NodeJS, You can found the complete code used in this tutorial here.
\n","frontmatter":{"date":"March 20, 2020","updated_date":null,"title":"NodeJS and MongoDB application authentication by JWT","tags":["NodeJs","JWT","MongoDB","Authentication","JSON Web Token"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.6666666666666667,"src":"/static/2b39d6f99b1ca5d4bc89d3bfccb6e29d/e9589/jwt.webp","srcSet":"/static/2b39d6f99b1ca5d4bc89d3bfccb6e29d/61e93/jwt.webp 200w,\n/static/2b39d6f99b1ca5d4bc89d3bfccb6e29d/1f5c5/jwt.webp 400w,\n/static/2b39d6f99b1ca5d4bc89d3bfccb6e29d/e9589/jwt.webp 500w","sizes":"(max-width: 500px) 100vw, 500px"}}},"author":{"id":"Ashish Sharma","github":"ashish8947","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/using-jwt-with-oauth2-when-and-why/"},"html":"JWT(Json Web Token) is a token format. It is digitally-signed, self-contained, and compact. It provides a convenient mechanism for transferring data. JWT is not inherently secure, but the use of JWT can ensure the authenticity of the message so long as the signature is verified and the integrity of the payload can be guaranteed. JWT is often used for stateless authentication in simple use cases involving non-complex systems.
\nOAuth2 is an authorization protocol that builds upon the original OAuth protocol created in 2006, arising out of a need for authorization flows serving different kinds of applications from web and mobile apps to IoT. OAuth2 specifies the flows and standards under which authorization token exchanges should occur. OAuth2 does not encompass authentication, only authorization. For more information on OAuth2, please see IETF
\nJWT and OAuth2 are entirely different and serve different purposes, but they are compatible and can be used together. The OAuth2 protocol does not specify the format of the tokens, therefore JWTs can be incorporated into the usage of OAuth2.
\nFor example, the access_token returned from the OAuth2 Authorization Server could be a JWT carrying additional information in the payload. This could potentially increase performance by reducing round trips for the required information between the Resource Server and the Authorization Server. This is a good use case for incorporating JWT into OAuth2 implementations when transparent tokens are acceptable - there are scenarios requiring token opacity where this is not optimal.
\nAnother common way to use JWT in conjunction with OAuth2 is to issue two tokens: a reference token as access_token, and a JWT containing identity information in addition to that access token. In use cases where this implementation seems necessary, it is probably worth looking into OpenID Connect - an extension built upon OAuth2 and provides additional standardizations, including having an access_token and an id_token.
\nA common misconception is that using JWT with OAuth2 increases the security of an application, this is not true. As mentioned earlier, JWT is not an inherently secure mechanism, and the security of OAuth2 is upheld through the definitions of the actors involved in the authorization process and the specific steps to be taken for this process in different use cases. Security concerns regarding OAuth2 are best addressed by choosing the appropriate OAuth2 grant flow for the application based on use case, not the token format.
\nThe advantages of using JWT in addition to OAuth2 is in increased performance and decreased process complexity when it comes to certain flows; however, this may increase development complexity. When deciding whether to use JWT on top of OAuth2, it is best to begin by considering whether the performance gain is meaningful to your application, and whether that is worth the additional work required for development.
\n","frontmatter":{"date":"March 11, 2019","updated_date":null,"title":"How to Use JWT with OAuth","tags":["JWT","Oauth","JSON Web Token"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/6bb161407bb0fc97a9525faaae5de564/58556/photo-1454165804606-c3d57bc86b40.webp","srcSet":"/static/6bb161407bb0fc97a9525faaae5de564/61e93/photo-1454165804606-c3d57bc86b40.webp 200w,\n/static/6bb161407bb0fc97a9525faaae5de564/1f5c5/photo-1454165804606-c3d57bc86b40.webp 400w,\n/static/6bb161407bb0fc97a9525faaae5de564/58556/photo-1454165804606-c3d57bc86b40.webp 800w,\n/static/6bb161407bb0fc97a9525faaae5de564/99238/photo-1454165804606-c3d57bc86b40.webp 1200w,\n/static/6bb161407bb0fc97a9525faaae5de564/5616c/photo-1454165804606-c3d57bc86b40.webp 1350w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Ti Zhang","github":null,"avatar":null}}}},{"node":{"fields":{"slug":"/engineering/jwt/"},"html":"A JSON Web Token (JWT) is a JSON object that is defined in RFC 7519 as a safe way of transmitting information between two parties. Information in the JWT is digitally-signed, so that it can be verified and trusted.
\nJWT Properties
\nJWT Use Cases
\nJWT contains three parts: Header, Payload, and Signature which are separated by a dot.
\nHeader.Payload.Signature
Header
\nThe JWT Header consists of 2 parts:
\n{ \n "typ" : "JWT", \n "alg" : "HS256" \n}Header Algorithm Types:
\nalg Value
\nDigital Signature or MAC Algorithm
\n| Algo | \nDescription | \n
|---|---|
| HS256 | \nHMAC using SHA-256 hash algorithm | \n
| HS384 | \nHMAC using SHA-384 hash algorithm | \n
| HS512 | \nHMAC using SHA-512 hash algorithm | \n
| RS256 | \nRSASSA using SHA-256 hash algorithm | \n
| RS384 | \nRSASSA using SHA-384 hash algorithm | \n
| RS512 | \nRSASSA using SHA-512 hash algorithm | \n
| ES256 | \nECDSA using P-256 curve and SHA-256 hash algorithm | \n
| ES384 | \nECDSA using P-384 curve and SHA-384 hash algorithm | \n
| ES512 | \nECDSA using P-521 curve and SHA-512 hash algorithm | \n
The Base64Url-encoded Header, which is first part of our JWT, looks like the following:
\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload
\nThe Payload, also known as the JWT claim, contains all of the information we want to transmit.
\nDifferent types of claims can be used to build the Payload:
\n| Code | \nName | \nDescription | \n
|---|---|---|
| iss | \nissuer | \nIdentifies the principal that issued the JWT. | \n
| sub | \nsubject | \nIdentifies the principal that is the subject of the JWT. | \n
| aud | \naudience | \nIdentifies the recipients that the JWT is intended for. | \n
| exp | \nExpiration time | \nIdentifies the expiration time on or after which the JWT MUST NOT be accepted for processing. | \n
| nbf | \nNot before | \nIdentifies the time before which the JWT MUST NOT be accepted for processing. | \n
| iat | \nIssue at | \nIdentifies the time at which the JWT was issued. | \n
| jti | \nJWT id | \nUnique identifier for the JWT, can be used to prevent the JWT from being replayed. | \n
Example Payload:
\n{ \n "sub": "1234567890", \n "name": "Frank Emic", \n "jti": "4b5fcea6-2a5e-4a9d-97f2-3d8631ea2c5a", \n "iat": 1521191902, \n "exp": 1521195630 \n}This example contains a combination of registered and public claims. “sub”,”jti”,”iat”, and “exp” are registered claims and “name” is a public claim.
\nThe Base64Url-encoded Payload, which is the second part of our JWT, looks like the following:
\neyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkZyYW5rIEVtaWMiL \nCJqdGkiOiI0YjVmY2VhNi0yYTVlLTRhOWQtOTdmMi0zZDg2MzFlYTJjNWEiLCJpYXQiOjE1MjExOTE5MDIsImV4cCI6MTUyMTE5NTYzMH0Signature
\nThe final part of our JWT is the Signature. To create the Signature, we need 3 components:
\nvar encodedString = base64UrlEncode(header) + \".\" + base64UrlEncode(payload);
\nHMACSHA256(encodedString, 'secret');
The secret is the Signature held by the server in order to verify tokens and sign new ones.
\nThe above Base64Url-encoded Header and Payload are combined with a dot, and then digitally-signed using the secret. This generates the Signature as the third part of the our JWT:
\nwGDoDSxfKj3Ns379NVxocwM9TOiwxhxWl
\nPutting It All Together
\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkZyYW5rIEVtaWMiL \nCJqdGkiOiI0YjVmY2VhNi0yYTVlLTRhOWQtOTdmMi0zZDg2MzFlYTJjNWEiLCJpYXQiOjE1MjExOTE5MDIsImV4cCI6MTUyMTE5NTYzMH0.wGDoDSxfKj3Ns379NVxocwM9TOiwxhxWlThis is our final JWT, containing the Header, Payload, and Signature joined together with dots. It can be passed as a URL parameter, a POST parameter, or in the HTTP header to authenticate or exchange information.
\nNote: JWT does not hide information; it just encodes information using the digitally-signed signature and verifies that the information has not been altered over the network. So, do not add any sensitive information in the JWT claim.
\nConclusion
\nJWT comprises three encoded parts: Header, Payload, and Signature. It can be passed as a URL or POST parameter, or in an HTTP header. Due to JWT's lightweight, self-containing, and versatile strucutre, it remains a popular tool for information exchange and authentication.
\n","frontmatter":{"date":"July 11, 2018","updated_date":null,"title":"What is JSON Web Token","tags":["JWT","JSON Web Token"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.7699115044247788,"src":"/static/fca016963236696b6d07a52d211c1354/58556/jwt.webp","srcSet":"/static/fca016963236696b6d07a52d211c1354/61e93/jwt.webp 200w,\n/static/fca016963236696b6d07a52d211c1354/1f5c5/jwt.webp 400w,\n/static/fca016963236696b6d07a52d211c1354/58556/jwt.webp 800w,\n/static/fca016963236696b6d07a52d211c1354/99238/jwt.webp 1200w,\n/static/fca016963236696b6d07a52d211c1354/135cd/jwt.webp 1280w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Mayank Agarwal","github":"mayankagrwal","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/alternate-authentication-asp/"},"html":"Introduction
\nAuthentication and authorization both are most important things for any system and application. This blog starts with authentication and authorization concepts and after that explains the three default important ways and three custom authentication ways for doing authentication and authorization i.e. windows, forms ,passport, multipass, JWT and SAML authentication. Plus, in this blog I will explain some fundamental concepts about the different authentication system.
\nAuthentication and Authorization
\nAuthentication is the process for checking the identity of a user based on the user’s credentials. Generally, user’s credentials are in the form of user ID and password, and we check their credentials from database or equivalent alternative, if it exists then user is a valid candidate for next process - authorization.
\nAuthorization also known as “Permission Control” will come after authentication. Authorization is the process of deciding what kind of resource a user can access based on their identity and checking whether the authenticated user has sufficient rights to access the requested resources. Typically a resource can be an ASP.NET web page, media files (MP4, GIF, JPEG etc), compressed file (ZIP, RAR) etc.
\nASP.NET default authentication Providers
\n1. Form Authentication
\nNormally, form authentication is based on cookies, the authentication and permission settings are stored in cookies. However, we can also use form authentication without cookies, and in cookie-less form authentication we can use query string for passing user details. Remember, the key concept is always ONLY allow the user with correct credential also enough permission to view certain resources, so we need to capture their information and compare with what we have stored in the database. And no matter what kind of form authentication we use, after we receive the data on server end, we will compare them with the data stored in any storage method/provider. For example, we can store username and password in the web.config file, a JSON file, or a database table.
\nForms authentication flow:
\n2. Passport Authentication
\nPassport authentication is a centralized authentication service provided by Microsoft. The .NET Passport single sign-in service. When we use passport authentication then user authentication in your application is managed by Microsoft's passport service. Passport authentication uses encrypted cookies to manage the authentication.
\nHow Password authentication works Users do not need to retype their sign-in name and password when moving from site to site. Those .NET Passport–enabled sites will issue a set of encrypted cookies in the .NET Passport central servers' domain to facilitate silent and seamless sign-in across sites. In some cases, sites owners will first redirect their end-users to .NET Passport sign-in and to authenticate upon first viewing of their site. If the users are logged in already, they'll get authenticated by ASP.NET, and if they are not logged in they will get redirected to passport servers (i.e hotmail, Live etc.) to login first. If user successfully authenticates himself, it will return a token to your website.
\n3. Windows Authentication
\nWe use windows authentication when we are creating a web application for a limited number of users who already have Windows account and this type of authentication is quite useful in an intranet environment. This authentication method uses local users windows account 'credentials' for to validate the user. Dot Net web application generally hosted on IIS(Internet Information Server) so the requests go directly to IIS to provide the authentication process in a Windows-based authentication model.
\nThe entire responsibility of authentication is done by IIS. It first takes the user’s credentials from the domain login. If this process fails, IIS displays an alert dialog box so the user can enter or re-enter his login information.
\nWindows authentication have some advantages and disadvantages:
\nWindows authentication Advantage
\nWindows authentication dis-Advantage
\n4. Custom authentication Provider
\nMultipass authentication is a single sign on authentication. Suppose you have multiple sites and you want to create a single account for a user on both sites then you can use Single Sign-On. Single Sign-On is authentication system it allow user to share his authentication details with your there site. This allows a seamless experience for your users without forcing them to create a separate account on your second site. A multipass is simply a hash of keys and values, provided as an AES encrypted JSON hash.
\nJWTs represent a set of claims as a JSON object that is encoded in a JWS and/or JWE structure. This JSON object is called “JWT Claims Set”. The JSON object consists of zero or more name/value pairs (or members), where the names are strings and the values are arbitrary JSON values. These members are the claims represented by the JWT.
\nYour JWTs can contain any information you want; the user's name, birthdate, email, etc. You do this with claims based authorization. You then just tell your provider to make a JWT with these claims from the claims principle.
\nSAML - Security Assertion Markup Language SAML. SAML is developed by the Security Services Technical Committee of \"Organization for the Advancement of Structured Information Standards\" (OASIS). SAML is an XML-based framework for exchanging user authentication. The purpose of SAML is to enable Single Sign-On for web applications across various domains.
\nSAML have three components: assertions, protocol, and binding. Assertions are authentication, attribute, and authorization. Authentication assertion validates the user's identity. Attribute assertion contains specific information about the user. And authorization assertion identifies user role and permissions.
\nSAML works with multiple protocols including Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP) and also supports SOAP
\nSummary
\nDifferent authentication methods are available, and website’s owner always gets confused about which authentication method they should use, here I have explained some of the popular authentication and authorization methods, hope it made it a little bit clear for you. And I will provide some in-depth details about each type of authentication in my next blog, happy coding.
\n","frontmatter":{"date":"October 01, 2015","updated_date":null,"title":"Types of Authentication in Asp.Net","tags":["Engineering","Authentication","Asp.Net","Multipass","JWT","JSON Web Token"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/051582b8bfe0e3796cdccd575e275a97/e7487/alternate-authentication-asp-dot-net1-150x150.webp","srcSet":"/static/051582b8bfe0e3796cdccd575e275a97/e7487/alternate-authentication-asp-dot-net1-150x150.webp 150w","sizes":"(max-width: 150px) 100vw, 150px"}}},"author":{"id":"Team LoginRadius","github":"LoginRadius","avatar":null}}}}]}},"pageContext":{"tag":"JSON Web Token"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}