diff --git a/v2/emailpassword/common-customizations/sessions/with-jwt/jwt-verification.mdx b/v2/emailpassword/common-customizations/sessions/with-jwt/jwt-verification.mdx index f30f0fab6..ed8575a0f 100644 --- a/v2/emailpassword/common-customizations/sessions/with-jwt/jwt-verification.mdx +++ b/v2/emailpassword/common-customizations/sessions/with-jwt/jwt-verification.mdx @@ -28,7 +28,7 @@ There are three steps in doing session verification using JWTs: ### Method 1) Using JWKS endpoint (recommended) - + @@ -80,13 +80,22 @@ Refer to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a - This function takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. - `main.go`: This is an example of how to verify a JWT using the golang JWT verification lib along with our helper function to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + + + +Refer to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd) for a code reference of how use the Java `nimbus-jose-jwt` lib to do session verification. The gist contains three files: +- `JWTVerification.java` You will have to modify the `CORE_URL` in this file to point to your supertokens core instance (replacing the `try.supertokens.com` part of the URL). + - This is an example of how to verify a JWT using the Java `nimbus-jose-jwt` lib along with our helper method to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + - This file has a method called `setSource` which returns a reference to the JWKS public keys that can be used for JWT verification. This method takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. +- `pom.xml`: This shows the version of `nimbus-jose-jwt` used for this project. +- `InvalidClaimsException.java`: This holds the custom Exception we throw when someone has an invalid JWT body, hasn't verified their email, or hasn't set up MFA. ### Method 2) Using public key string - + :::caution @@ -213,13 +222,20 @@ Not applicable. Please use method 1 instead. Not applicable. Please use method 1 instead. ::: + + + +:::caution +Not applicable. Please use method 1 instead. +::: + ## Check for custom claim values for authorization - + Once you have verified the access token, you can fetch the payload and do authorization checks based on the values of the custom claims. For examlpe, if you want to do check for if the user's email is verified, you should check the `st-ev` claim in the payload as shown below: @@ -269,6 +285,11 @@ Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a5b86481e72032abf8d), we can see in `main.go`, between lines 32 and 44, that we are checking for the `st-ev` claim in the JWT payload. If the claim is not present or is set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. + + + +Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd), we can see in `JWTVerification.java`, between lines 42 and 58, that we are checking for the `st-ev` and `st-mfa` claims in the JWT payload. If the claims are not present or are set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. + diff --git a/v2/passwordless/common-customizations/sessions/with-jwt/jwt-verification.mdx b/v2/passwordless/common-customizations/sessions/with-jwt/jwt-verification.mdx index f30f0fab6..ed8575a0f 100644 --- a/v2/passwordless/common-customizations/sessions/with-jwt/jwt-verification.mdx +++ b/v2/passwordless/common-customizations/sessions/with-jwt/jwt-verification.mdx @@ -28,7 +28,7 @@ There are three steps in doing session verification using JWTs: ### Method 1) Using JWKS endpoint (recommended) - + @@ -80,13 +80,22 @@ Refer to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a - This function takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. - `main.go`: This is an example of how to verify a JWT using the golang JWT verification lib along with our helper function to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + + + +Refer to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd) for a code reference of how use the Java `nimbus-jose-jwt` lib to do session verification. The gist contains three files: +- `JWTVerification.java` You will have to modify the `CORE_URL` in this file to point to your supertokens core instance (replacing the `try.supertokens.com` part of the URL). + - This is an example of how to verify a JWT using the Java `nimbus-jose-jwt` lib along with our helper method to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + - This file has a method called `setSource` which returns a reference to the JWKS public keys that can be used for JWT verification. This method takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. +- `pom.xml`: This shows the version of `nimbus-jose-jwt` used for this project. +- `InvalidClaimsException.java`: This holds the custom Exception we throw when someone has an invalid JWT body, hasn't verified their email, or hasn't set up MFA. ### Method 2) Using public key string - + :::caution @@ -213,13 +222,20 @@ Not applicable. Please use method 1 instead. Not applicable. Please use method 1 instead. ::: + + + +:::caution +Not applicable. Please use method 1 instead. +::: + ## Check for custom claim values for authorization - + Once you have verified the access token, you can fetch the payload and do authorization checks based on the values of the custom claims. For examlpe, if you want to do check for if the user's email is verified, you should check the `st-ev` claim in the payload as shown below: @@ -269,6 +285,11 @@ Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a5b86481e72032abf8d), we can see in `main.go`, between lines 32 and 44, that we are checking for the `st-ev` claim in the JWT payload. If the claim is not present or is set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. + + + +Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd), we can see in `JWTVerification.java`, between lines 42 and 58, that we are checking for the `st-ev` and `st-mfa` claims in the JWT payload. If the claims are not present or are set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. + diff --git a/v2/session/common-customizations/sessions/with-jwt/jwt-verification.mdx b/v2/session/common-customizations/sessions/with-jwt/jwt-verification.mdx index 771b66071..2d5d4e633 100644 --- a/v2/session/common-customizations/sessions/with-jwt/jwt-verification.mdx +++ b/v2/session/common-customizations/sessions/with-jwt/jwt-verification.mdx @@ -28,7 +28,7 @@ There are three steps in doing session verification using JWTs: ### Method 1) Using JWKS endpoint (recommended) - + @@ -80,13 +80,22 @@ Refer to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a - This function takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. - `main.go`: This is an example of how to verify a JWT using the golang JWT verification lib along with our helper function to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + + + +Refer to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd) for a code reference of how use the Java `nimbus-jose-jwt` lib to do session verification. The gist contains three files: +- `JWTVerification.java` You will have to modify the `CORE_URL` in this file to point to your supertokens core instance (replacing the `try.supertokens.com` part of the URL). + - This is an example of how to verify a JWT using the Java `nimbus-jose-jwt` lib along with our helper method to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + - This file has a method called `setSource` which returns a reference to the JWKS public keys that can be used for JWT verification. This method takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. +- `pom.xml`: This shows the version of `nimbus-jose-jwt` used for this project. +- `InvalidClaimsException.java`: This holds the custom Exception we throw when someone has an invalid JWT body, hasn't verified their email, or hasn't set up MFA. ### Method 2) Using public key string - + :::caution @@ -213,13 +222,20 @@ Not applicable. Please use method 1 instead. Not applicable. Please use method 1 instead. ::: + + + +:::caution +Not applicable. Please use method 1 instead. +::: + ## Check for custom claim values for authorization - + Once you have verified the access token, you can fetch the payload and do authorization checks based on the values of the custom claims. For examlpe, if you want to do check for if the user's email is verified, you should check the `st-ev` claim in the payload as shown below: @@ -269,6 +285,11 @@ Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a5b86481e72032abf8d), we can see in `main.go`, between lines 32 and 44, that we are checking for the `st-ev` claim in the JWT payload. If the claim is not present or is set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. + + + +Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd), we can see in `JWTVerification.java`, between lines 42 and 58, that we are checking for the `st-ev` and `st-mfa` claims in the JWT payload. If the claims are not present or are set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. + diff --git a/v2/src/components/tabs/BackendSDKTabs.tsx b/v2/src/components/tabs/BackendSDKTabs.tsx index cd2d25906..c212bbaaa 100644 --- a/v2/src/components/tabs/BackendSDKTabs.tsx +++ b/v2/src/components/tabs/BackendSDKTabs.tsx @@ -16,6 +16,9 @@ export default function BackendSDKTabs(props: any) { if (!props.disablePython) { values.push({ label: 'Python', value: 'python' }); } + if (props.enableJava) { + values.push({ label: 'Java', value: 'java' }); + } if (props.enableCurl) { values.push({ label: 'cURL', value: 'curl' }); } diff --git a/v2/thirdparty/common-customizations/sessions/with-jwt/jwt-verification.mdx b/v2/thirdparty/common-customizations/sessions/with-jwt/jwt-verification.mdx index f30f0fab6..ed8575a0f 100644 --- a/v2/thirdparty/common-customizations/sessions/with-jwt/jwt-verification.mdx +++ b/v2/thirdparty/common-customizations/sessions/with-jwt/jwt-verification.mdx @@ -28,7 +28,7 @@ There are three steps in doing session verification using JWTs: ### Method 1) Using JWKS endpoint (recommended) - + @@ -80,13 +80,22 @@ Refer to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a - This function takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. - `main.go`: This is an example of how to verify a JWT using the golang JWT verification lib along with our helper function to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + + + +Refer to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd) for a code reference of how use the Java `nimbus-jose-jwt` lib to do session verification. The gist contains three files: +- `JWTVerification.java` You will have to modify the `CORE_URL` in this file to point to your supertokens core instance (replacing the `try.supertokens.com` part of the URL). + - This is an example of how to verify a JWT using the Java `nimbus-jose-jwt` lib along with our helper method to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + - This file has a method called `setSource` which returns a reference to the JWKS public keys that can be used for JWT verification. This method takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. +- `pom.xml`: This shows the version of `nimbus-jose-jwt` used for this project. +- `InvalidClaimsException.java`: This holds the custom Exception we throw when someone has an invalid JWT body, hasn't verified their email, or hasn't set up MFA. ### Method 2) Using public key string - + :::caution @@ -213,13 +222,20 @@ Not applicable. Please use method 1 instead. Not applicable. Please use method 1 instead. ::: + + + +:::caution +Not applicable. Please use method 1 instead. +::: + ## Check for custom claim values for authorization - + Once you have verified the access token, you can fetch the payload and do authorization checks based on the values of the custom claims. For examlpe, if you want to do check for if the user's email is verified, you should check the `st-ev` claim in the payload as shown below: @@ -269,6 +285,11 @@ Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a5b86481e72032abf8d), we can see in `main.go`, between lines 32 and 44, that we are checking for the `st-ev` claim in the JWT payload. If the claim is not present or is set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. + + + +Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd), we can see in `JWTVerification.java`, between lines 42 and 58, that we are checking for the `st-ev` and `st-mfa` claims in the JWT payload. If the claims are not present or are set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. + diff --git a/v2/thirdpartyemailpassword/common-customizations/sessions/with-jwt/jwt-verification.mdx b/v2/thirdpartyemailpassword/common-customizations/sessions/with-jwt/jwt-verification.mdx index f30f0fab6..ed8575a0f 100644 --- a/v2/thirdpartyemailpassword/common-customizations/sessions/with-jwt/jwt-verification.mdx +++ b/v2/thirdpartyemailpassword/common-customizations/sessions/with-jwt/jwt-verification.mdx @@ -28,7 +28,7 @@ There are three steps in doing session verification using JWTs: ### Method 1) Using JWKS endpoint (recommended) - + @@ -80,13 +80,22 @@ Refer to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a - This function takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. - `main.go`: This is an example of how to verify a JWT using the golang JWT verification lib along with our helper function to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + + + +Refer to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd) for a code reference of how use the Java `nimbus-jose-jwt` lib to do session verification. The gist contains three files: +- `JWTVerification.java` You will have to modify the `CORE_URL` in this file to point to your supertokens core instance (replacing the `try.supertokens.com` part of the URL). + - This is an example of how to verify a JWT using the Java `nimbus-jose-jwt` lib along with our helper method to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + - This file has a method called `setSource` which returns a reference to the JWKS public keys that can be used for JWT verification. This method takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. +- `pom.xml`: This shows the version of `nimbus-jose-jwt` used for this project. +- `InvalidClaimsException.java`: This holds the custom Exception we throw when someone has an invalid JWT body, hasn't verified their email, or hasn't set up MFA. ### Method 2) Using public key string - + :::caution @@ -213,13 +222,20 @@ Not applicable. Please use method 1 instead. Not applicable. Please use method 1 instead. ::: + + + +:::caution +Not applicable. Please use method 1 instead. +::: + ## Check for custom claim values for authorization - + Once you have verified the access token, you can fetch the payload and do authorization checks based on the values of the custom claims. For examlpe, if you want to do check for if the user's email is verified, you should check the `st-ev` claim in the payload as shown below: @@ -269,6 +285,11 @@ Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a5b86481e72032abf8d), we can see in `main.go`, between lines 32 and 44, that we are checking for the `st-ev` claim in the JWT payload. If the claim is not present or is set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. + + + +Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd), we can see in `JWTVerification.java`, between lines 42 and 58, that we are checking for the `st-ev` and `st-mfa` claims in the JWT payload. If the claims are not present or are set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. + diff --git a/v2/thirdpartypasswordless/common-customizations/sessions/with-jwt/jwt-verification.mdx b/v2/thirdpartypasswordless/common-customizations/sessions/with-jwt/jwt-verification.mdx index f30f0fab6..ed8575a0f 100644 --- a/v2/thirdpartypasswordless/common-customizations/sessions/with-jwt/jwt-verification.mdx +++ b/v2/thirdpartypasswordless/common-customizations/sessions/with-jwt/jwt-verification.mdx @@ -28,7 +28,7 @@ There are three steps in doing session verification using JWTs: ### Method 1) Using JWKS endpoint (recommended) - + @@ -80,13 +80,22 @@ Refer to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a - This function takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. - `main.go`: This is an example of how to verify a JWT using the golang JWT verification lib along with our helper function to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + + + +Refer to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd) for a code reference of how use the Java `nimbus-jose-jwt` lib to do session verification. The gist contains three files: +- `JWTVerification.java` You will have to modify the `CORE_URL` in this file to point to your supertokens core instance (replacing the `try.supertokens.com` part of the URL). + - This is an example of how to verify a JWT using the Java `nimbus-jose-jwt` lib along with our helper method to get the JWKs keys. If you are using header based auth, you can fetch the JWT from the `Authorization Bearer` header, otherwise for cookie based auth, you can fetch it from the `sAccessToken` cookie. + - This file has a method called `setSource` which returns a reference to the JWKS public keys that can be used for JWT verification. This method takes care of caching public keys in memory + auto refetching if the public keys have changed (which happens automatically every 24 hours with supertokens). This will not cause any user logouts, and is just a security feature. +- `pom.xml`: This shows the version of `nimbus-jose-jwt` used for this project. +- `InvalidClaimsException.java`: This holds the custom Exception we throw when someone has an invalid JWT body, hasn't verified their email, or hasn't set up MFA. ### Method 2) Using public key string - + :::caution @@ -213,13 +222,20 @@ Not applicable. Please use method 1 instead. Not applicable. Please use method 1 instead. ::: + + + +:::caution +Not applicable. Please use method 1 instead. +::: + ## Check for custom claim values for authorization - + Once you have verified the access token, you can fetch the payload and do authorization checks based on the values of the custom claims. For examlpe, if you want to do check for if the user's email is verified, you should check the `st-ev` claim in the payload as shown below: @@ -269,6 +285,11 @@ Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/8c26ed237add1a5b86481e72032abf8d), we can see in `main.go`, between lines 32 and 44, that we are checking for the `st-ev` claim in the JWT payload. If the claim is not present or is set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. + + + +Referring once again to this [Github gist](https://gist.github.com/rishabhpoddar/5b2d19c02337ed7ee387723c84def9cd), we can see in `JWTVerification.java`, between lines 42 and 58, that we are checking for the `st-ev` and `st-mfa` claims in the JWT payload. If the claims are not present or are set to `false`, we send a `403` to the frontend which will cause our frontend SDK (pre built UI SDK) to recheck the claims added on the frontend and navigate to the right screen. +