Add java examples to jwt-verification.

supertokens · Jul 22, 2024 · c3818be · c3818be
1 parent 16e66a9
commit c3818be
Show file tree

Hide file tree

Showing 7 changed files with 147 additions and 18 deletions.
diff --git 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)
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 
@@ -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.
 
+</TabItem>
+<TabItem value="java">
+
+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.
 
 </TabItem>
 </BackendSDKTabs>
 
 ### Method 2) Using public key string
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 :::caution
@@ -213,13 +222,20 @@ Not applicable. Please use method 1 instead.
 Not applicable. Please use method 1 instead.
 :::
 
+</TabItem>
+<TabItem value="java">
+
+:::caution
+Not applicable. Please use method 1 instead.
+:::
+
 </TabItem>
 </BackendSDKTabs>
 
 
 ## Check for custom claim values for authorization
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 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.
 
+</TabItem>
+<TabItem value="java">
+
+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.
+
 </TabItem>
 </BackendSDKTabs>
 

diff --git 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)
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 
@@ -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.
 
+</TabItem>
+<TabItem value="java">
+
+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.
 
 </TabItem>
 </BackendSDKTabs>
 
 ### Method 2) Using public key string
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 :::caution
@@ -213,13 +222,20 @@ Not applicable. Please use method 1 instead.
 Not applicable. Please use method 1 instead.
 :::
 
+</TabItem>
+<TabItem value="java">
+
+:::caution
+Not applicable. Please use method 1 instead.
+:::
+
 </TabItem>
 </BackendSDKTabs>
 
 
 ## Check for custom claim values for authorization
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 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.
 
+</TabItem>
+<TabItem value="java">
+
+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.
+
 </TabItem>
 </BackendSDKTabs>
 

diff --git 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)
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 
@@ -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.
 
+</TabItem>
+<TabItem value="java">
+
+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.
 
 </TabItem>
 </BackendSDKTabs>
 
 ### Method 2) Using public key string
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 :::caution
@@ -213,13 +222,20 @@ Not applicable. Please use method 1 instead.
 Not applicable. Please use method 1 instead.
 :::
 
+</TabItem>
+<TabItem value="java">
+
+:::caution
+Not applicable. Please use method 1 instead.
+:::
+
 </TabItem>
 </BackendSDKTabs>
 
 
 ## Check for custom claim values for authorization
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 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.
 
+</TabItem>
+<TabItem value="java">
+
+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.
+
 </TabItem>
 </BackendSDKTabs>
 

diff --git 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
@@ -28,7 +28,7 @@ There are three steps in doing session verification using JWTs:
 
 ### Method 1) Using JWKS endpoint (recommended)
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 
@@ -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.
 
+</TabItem>
+<TabItem value="java">
+
+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.
 
 </TabItem>
 </BackendSDKTabs>
 
 ### Method 2) Using public key string
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 :::caution
@@ -213,13 +222,20 @@ Not applicable. Please use method 1 instead.
 Not applicable. Please use method 1 instead.
 :::
 
+</TabItem>
+<TabItem value="java">
+
+:::caution
+Not applicable. Please use method 1 instead.
+:::
+
 </TabItem>
 </BackendSDKTabs>
 
 
 ## Check for custom claim values for authorization
 
-<BackendSDKTabs disableOtherFrameworks={true}>
+<BackendSDKTabs disableOtherFrameworks={true} enableJava={true}>
 <TabItem value="nodejs">
 
 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.
 
+</TabItem>
+<TabItem value="java">
+
+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.
+
 </TabItem>
 </BackendSDKTabs>