認證令牌

“我喜歡編寫身份驗證和授權代碼。” ?從來沒有Web開發人員。 厭倦了一次又一次地建立相同的登錄屏幕？ 嘗試使用Okta API進行托管身份驗證，授權和多因素身份驗證。

JSON Web令牌已Swift成為保護Web應用程序安全的標準，并取代了Cookie和會話等舊技術。 正確使用它們可以解決一系列安全問題，包括跨站點腳本攻擊（XSS），中間人攻擊（MITM）和跨站點請求偽造（CSRF）。 它們還為我們提供了可檢查的元數據和強大的密碼簽名的好處。 在本文中，我將深入探討JWT。 首先，我將介紹一些理論基礎，解釋它們如何工作。 之后，我將向您展示如何使用Okta配置Spring Boot應用程序以使用JWT身份驗證。

JSON Web令牌是一個開放標準，并且有許多可用的庫允許創建，驗證和檢查JWT。 您將使用Java JWT （又名JJWT），這是一個提供端到端JWT創建和驗證的Java庫。 JJWT由Les Hazlewood創建， Les Hazlewood是Stormpath的前聯合創始人兼CTO Apache Shiro的主要撰稿人，目前是Okta自己的高級架構師。 根據Apache 2.0許可，它是開源的。

了解JWT及其在身份驗證中的作用

首先讓我們研究一下authentication和token在這種情況下的含義。

身份驗證證明用戶就是他們所說的真實身份 。

令牌是一個獨立的信息塊。 它可能具有內在價值，也可能沒有。 我將向您展示一種特定類型的令牌， 它確實具有內在價值，并通過會話ID解決了許多問題。

什么是JSON Web令牌？ JWT是一種開放標準（ RFC 7519 ），用于使用JSON在各方之間作為數字簽名的字符串令牌傳輸信息。 可以使用HMAC算法或使用RSA或ECDSA的公用/專用密鑰對對它們進行簽名 。

換句話說：JWT是JSON令牌，是URL安全，緊湊且自包含的字符串。 通常，它們攜帶有關用戶的已驗證身份的信息。 它們通常經過編碼和加密。 它們Swift成為網絡上令牌實現的事實上的標準。 URL安全意味著令牌字符串可以在URL中使用，因為所有特殊字符都已被編碼為簡單的字母數字字符。 JWT也被認為是不透明的，因為字符串本身沒有解碼或解密就不會提供任何信息。

令牌通常被認為是一種授權機制，但是它們也可以用作在Web應用程序和服務器之間安全地存儲和傳輸信息的一種方式，與使用會話ID的方式非常相似。

將JWT與OAuth 2.0結合使用

許多OAuth 2.0實現將JWT用于其訪問令牌。 應該指出，OAuth 2.0和JWT規范是彼此完全獨立的，彼此之間沒有任何依賴關系。 將JWT用作OAuth 2.0的令牌機制可帶來很多好處，如下所示。

無論使用哪種JWT實施，都必須將漂亮的Web令牌存儲在某個地方。 Cookie和HTML5 Web存儲是兩個流行的選項。 兩種選擇都有好處和潛在風險。 對此的討論不在本文討論范圍之內，但是值得閱讀上面提到的典型攻擊：跨站點腳本攻擊（XSS），中間人攻擊（MITM）和跨站點請求偽造（CSRF）。 Okta使用HTML5網絡存儲。

無論將JWT存儲在何處，都可以用JWT完全替換會話ID，并獲得直接從會話ID / JWT訪問元信息的額外好處。

看一下JWT的結構

那是很多首字母縮寫詞。 讓我們看一下JWT。 在野外，JWT很害羞。 有些人甚至可能說他們太丑陋或無聊（取決于您對206個字符串的感覺）。

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOi8vdHJ1c3R5YXBwLmNvbS8iLCJleHAiOjEzMDA4MTkzODAsInN1YiI6InVzZXJzLzg5ODM0NjIiLCJzY29wZSI6InNlbGYgYXBpL2J1eSJ9.43DXvhrwMGeLLlP4P4izjgsBB2yrpo82oiUPhADakLs

就像生活中的大多數事情一樣，請不要憑空判斷JWT（請記住，它們是不透明的）。 如果仔細看，您會發現字符串中有兩個句點。 這些界定了JWT的不同部分：

標頭

有效載荷/主體（或要求）

密碼簽名。

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJodHRwOi8vdHJ1c3R5YXBwLmNvbS8iLCJleHAiOjEzMDA4MTkzODAsInN1YiI6InVzZXJzLzg5ODM0NjIiLCJzY29wZSI6InNlbGYgYXBpL2J1eSJ9 . 43DXvhrwMGeLLlP4P4izjgsBB2yrpo82oiUPhADakLs

窺視令牌頭

我知道我說過有些人認為JWT很無聊。 甚至不透明。 但是，如果您知道如何與他們交談，JWT非常有趣。 讓我們解碼示例??JWT并查看其中的內容。

標頭只是通過Base64Url編碼的。 它告訴我們令牌的類型和使用的哈希算法，通常是HMAC SHA256或RSA。

{"typ": "JWT","alg": "HS256" }

順便說一句， jsonwebtoken.io是用于編碼和解碼JWT的出色在線工具。

查看有效載荷

令牌的第二部分是有效負載或聲明 。

{"iss": "http://trustyapp.com/","exp": 1300819380,"sub": "users/8983462","scope": "self api/buy" }

有效負載包含聲明 。 聲明是有關實體（通常是用戶）和任何其他數據的聲明。 索賠有以下三種：

已注冊的聲明： RFC 7519規范中定義的一組建議的聲明。 一些示例是iss ， exp和aud 。

公共聲明：可由令牌用戶定義但應遵循命名約定以避免沖突的用戶定義聲明（應在IANA JSON Web令牌注冊表中定義或定義為包含抗沖突名稱空間的URI），因為它們在公共命名空間中。

私人聲明：用于在達成共識的各方之間共享信息的任意自定義聲明（不必擔心名稱沖突，因為它們是私有的）。

在上面的示例中：

• iss是發行令牌的人。 這是已注冊的索賠。
• exp是令牌過期的時間。 也是已注冊的索賠。
• 子是主題。 通常是一個用戶標識符。 也是已注冊的索賠。
• 作用域是OAuth 2.0常用的自定義私人聲明。

范圍聲明通常用于提供授權信息。 例如，讓應用程序知道用戶有權訪問應用程序的哪一部分。 當然，這并不能免除服務器執行自己的授權檢查的責任。 Web應用程序安全性的一般原則是冗余。 客戶端應用程序提供一個檢查點，服務器提供另一個檢查點。

JSON數據經過Base64URL編碼以創建編碼的有效負載。 編碼的標頭和有效負載用于創建簽名。

檢查令牌簽名

簽名是JWT結構的最后一部分。 它獲取標頭，然后有效負載向哈希算法添加一個秘密，并吐出與JWT其余部分中未更改的數據相對應的哈希。 使用簽名，客戶端應用程序和服務器可以驗證它們接收的令牌是原始的，未更改的令牌。

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret )

了解此簽名不提供機密性是非常重要的。 此信息是公開可見的。 簽名保證令牌未被篡改，但不會隱藏數據（小孩可以在叔叔的iPhone 4上解碼Base64）。 如果要發送敏感信息，必須對JWT進行加密。

通常以子權利要求的形式存儲用戶標識符的慣例。 當JWT簽名時，它稱為JWS。 加密后，稱為JWE。

無國籍是JWT的一大好處。 服務器不需要存儲任何會話數據。 它可以全部存儲在令牌中，并在應用程序和服務器之間來回傳遞。 這看似是一個奇怪的電子飛盤游戲，但此模型的伸縮性非常好（只要會話狀態相對較小，就應該確實如此）。 從JWT解碼會話狀態要比在每個請求上訪問數據庫僅從會話存儲中檢索一些基本用戶狀態信息快得多，并且性能更高。

使用Java創建和驗證JWT

我已經提到過我們的JJWT項目嗎？ 查看其GitHub頁面 。 這是針對Java的完全開源的JWT解決方案。

讓我們看一個使用JJWT創建JWT的示例。

import io.jsonwebtoken.Jwts; import io.jsonwebtoken.SignatureAlgorithm; byte[] key = getSignatureKey(); String jwt = Jwts.builder().setIssuer("http://trustyapp.com/") .setSubject("users/1300819380") .setExpiration(expirationDate) .put("scope", "self api/buy") .signWith(SignatureAlgorithm.HS256,key) .compact();

該庫使用了流暢的Builder API。 請注意用于設置聲明的設置器。 標準聲明具有預定義的設置器，例如setSubject("users/1300819380") ，而自定義聲明使用鍵值put()方法。 例如范圍聲明， put("scope", "self api/buy") 。

驗證JWT一樣容易。

String subject = "HACKER"; try { Jws jwtClaims = Jwts.parser().setSigningKey(key).parseClaimsJws(jwt); subject = claims.getBody().getSubject(); // OK, you can trust this JWT } catch (SignatureException e) { // don't trust this JWT! }

如果對JWT進行了任何篡改，則解析聲明將引發SignatureException并且subject變量的值將保持HACKER 。 如果它是有效的JWT，則將從中提取subject ： claims.getBody().getSubject() 。

了解OAuth 2.0以Java進行令牌身份驗證

稍后，您將使用Okta的OAuth 2.0實現創建Spring Boot應用程序。 但是首先，您應該確保了解什么是OAuth，什么不是OAuth。

簡而言之，OAuth 2.0是“授權的行業標準協議”（來自OAuth.net網站 ）。 授權意味著它為應用程序提供了一種方法，以確保用戶有權執行操作或訪問資源。 OAuth 2.0 不提供用于驗證用戶身份的工具。

那是身份驗證。

還有另一個稱為OpenID Connect或OIDC的協議層，通常與提供身份驗證的OAuth 2.0配對。 OIDC建立在OAuth 2.0之上，并提供一種驗證用戶身份的方法，通常是通過使用用戶名和密碼或使用許多社交登錄選項之一來使用戶登錄。 因為OIDC 確實與OAuth 2.0一起驗證用戶的身份，所以它們一起為Web應用程序和服務器提供了完整的身份驗證和授權協議。

記得：

• OIDC是身份驗證，還是我是誰？
• OAuth是授權，還是該怎么辦？

在Java中配置Okta OIDC應用程序以進行令牌認證

很快，您將像專家一樣生成和驗證JWT。 但是首先，您需要轉到developer.okta.com并創建一個OpenID Connect（OIDC）應用程序。 如果尚未注冊免費的開??發者帳戶。 我是否提到過它完全免費？

登錄到Okta開發人員儀表板。 轉到應用程序 ，然后單擊添加應用程序按鈕。

選擇Web應用程序類型，然后單擊Next 。

在下一頁上，您需要給新應用程序起一個易記的名稱。 您可以隨意命名。 您還需要選中“ 客戶端憑據”復選框。 這將激活您將要使用的client_credentials授予類型。

單擊完成 。

請注意下一頁底部的客戶端ID和客戶端密鑰 。 您稍后將需要這些。

安裝HTTPie

我們將使用一個很棒的命令行實用工具來運行一些示例：HTTPie。 如果尚未安裝，請訪問其網站并安裝。

申請JWT

時機已到。 我知道你很興奮 您終于要見識JWT。

我知道您很想去，但是您還需要執行一個初步的步驟。 您需要對上述Okta OIDC應用程序中的客戶端ID和客戶端密鑰進行編碼，以便在HTTP基本授權標頭中使用。

通用格式為：

Authorization: Basic Base64Encode(< your client id >:< your client secret >)

注意中間的: 。 獲取您的客戶ID，并使用冒號將其加入到您的客戶秘密中。 Base64對結果字符串進行編碼（提示：使用base64encode.org ）。 然后將其包含在您的請求中。 它看起來像這樣：

Authorization: Basic ABChZzU4NDg5YW1aTDCBCB4waDc6TUp3YWN4RU5WNzQ1bEdQNWJPdlFETV9iaDE5NGp1eHQ3SXJfdWEzQQ==

互聯網上有各種實用程序可以為您完成此任務。 盡管這些對教程和從頭開始開發可能會有所幫助，但出于顯而易見的原因，但使用它們來編碼生產憑證并不是一個好主意。

接下來，您需要的是Okta OIDC應用程序的令牌請求URL。 這將是您的Okta授權服務器的基本URL加/v1/token 。 從頂部菜單轉到API ，然后選擇“ 授權服務器” 。 查看默認服務器的Issuer URI 。 添加/v1/token 。

例如，類似： https://{yourOktaDomain}/oauth2/default/v1/token

使用HTTPie，您的終端命令將如下所示：

http -f POST https://{yourOktaDomain}/oauth2/default/v1/token \ 'Authorization: Basic MG9hZzU4NDg5YW1aTDBNRU4wa...' \ grant_type=client_credentials

這里發生了什么？

-f是表單標志。 Content-Type設置為application/x-www-form-urlencoded; charset=utf-8 application/x-www-form-urlencoded; charset=utf-8并使用key=value表示法分析命令行以獲取表單數據。

POST是HTTP請求類型。

https://{yourOktaDomain}/oauth2/default/v1/token是令牌請求URL。

'Authorization: Basic ...'設置基本auth標頭。

grant_type=client_credentials是一個表單值，它告訴Okta我們正在請求的授予類型。 稍后再詳細介紹。

如果運行此命令，請繼續！ –您將收到invalid scope錯誤。

HTTP/1.1 400 Bad Request Cache-Control: no-cache, no-store Connection: close Content-Type: application/json;charset=UTF-8 ...{"error": "invalid_scope","error_description": "The authorization server resource does not have any configured default scopes, 'scope' must be provided." }

使用client_credentials授予類型實際上只是一種方便。 這是一種授予類型，它使我們無需遵循瀏覽器重定向即可請求JWT。 client_credentials通常用于API交互。

根據OAuth規范 ，“客戶端使用客戶端憑據授予類型來獲取用戶上下文外部的訪問令牌。 客戶端通常使用它來訪問有關其自身的資源，而不是訪問用戶的資源。”

將Okta用作單一登錄提供程序（一種更常見的用例）時，可以使用“ 授權代碼授予” 。 這種授予類型（其中應用程序允許用戶登錄并交換訪問令牌的授權代碼），但是需要一系列重定向，而這些重定向將很難從命令行客戶端（例如HTTPie）進行管理。 因此，本教程使用“客戶端證書”授予類型來方便地演示一些基本的OAuth / JWT功能。

您希望能想到：“很好，但是范圍誤差呢？”

很高興你問！

范圍提供了一種定義和限制令牌授予的訪問權限的方法。 在授權和驗證用戶時，通常會使用一系列范圍，例如openid email profile 。 這些作用域告訴服務器，該應用程序希望訪問用戶的個人資料，電子郵件地址，并希望發出OpenID身份驗證請求。

客戶證書授予類型要求我們定義一個自定義范圍。 這就是invalid scope錯誤所抱怨的。

讓我們修復它！

添加自定義范圍

返回至developer.okta.com 。 從頂部菜單轉到API和授權服務器 。

從服務器列表中單擊默認服務器。

單擊“ 作用域”選項卡，然后單擊“ 添加作用域”按鈕。

將范圍命名為“ customScope”，對其進行描述，然后單擊“ 創建” 。 您需要匹配的名稱，但是描述是任意的。

再次運行令牌請求

重新運行請求，這次使用自定義范圍。

http -f POST https://{yourOktaDomain}/oauth2/default/v1/token \ 'Authorization: Basic MG9hZzU4NDg5YW1aTDBN...' \ grant_type=client_credentials \ scope=customScope

這次您將獲得令牌！

HTTP/1.1 200 OK Cache-Control: no-cache, no-store Connection: Keep-Alive Content-Type: application/json;charset=UTF-8 Pragma: no-cache ...{"access_token": "eyJraWQiOiJldjFpay1DS3UzYjJXS3QzSVl1MlJZc3...","expires_in": 3600,"scope": "customScope","token_type": "Bearer" }

注意Cache-Control和Pragma標頭。 您不希望此響應被緩存在任何地方。 access_token是瀏覽器在后續請求中將使用的內容。 請記住，不需要將JWT用作OAuth 2.0訪問令牌。 它們非常方便，因為您可以在其中編碼防篡改（并且可能是機密的）元數據。

使用您的訪問令牌

要在請求中包含訪問令牌，請使用類型為Bearer的Authorization標頭。 下面是一個示例GET請求。

GET /admin HTTP/1.1 Authorization: Bearer eyJraWQiOiJldjFpay1DS3UzYjJXS3QzSVl1MlJZc3...

輸入Spring Boot以使用Java進行令牌認證

您準備好使用Java嗎？ 我已經準備好使用Java。

您要做的第一件事是從GitHub存儲庫中克隆示例應用程序 。

現在，使用以下終端命令檢出start分支：

git clone -b start https://github.com/oktadeveloper/okta-spring-boot-token-auth-example.git

此應用程序非常簡單。 至少，它看起來超級簡單。 實際上，在后臺，Spring Boot和Okta做出了相當大的努力，以為您提供功能齊全的REST資源服務器，該服務器具有使用OAuth 2.0和Okta OIDC應用程序進行的JWT令牌身份驗證的功能。 AM！

唯一需要進行的配置是在src/main/resources/application.yml文件中。 您需要從上面創建的幾個步驟的Okta OIDC應用程序中填寫您的客戶端ID和客戶端密鑰 。 您使用這些來生成令牌。 它們大致（如果是斜視，則有點類似）對應于OIDC應用程序的用戶名和密碼。

server: port: 8080 okta: oauth2: issuer: https://{yourOktaDomain}/oauth2/default clientId: {yourClientId}clientSecret: {yourClientSecret}

這就是您需要做的！ 至此，您將擁有一個功能齊全（如果不是超級激動人心的話）的Spring Boot資源服務器。

該應用程序的入口點位于Application.java文件中：

@EnableResourceServer @SpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }

您會注意到這是老式的main()方法所在的地方。 這些天感覺有點像遺物，但這就是所有魔力的開始。 在每個愚蠢的貓視頻和Facebook激烈的政治辯論背后，都有一個main()方法開始了這一切。

您正在使用SpringApplication.run()方法來引導Spring框架，該框架將加載Application類。 這將拾取@EnableResourceServer和@SpringBootApplication批注。 @SpringBootApplication告訴Spring加載Spring Boot。 @EnableResourceServer將Spring Boot應用程序配置為通過OAuth令牌（可能與OAuth 2.0單一登錄相對）對請求進行身份驗證。

@EnableResourceServer有幾個含義，值得指出。 如果您看一下有關注釋的文檔 ，則會看到幾個要點：如果要配置資源服務器，則需要定義ResourceServerConfigurerAdapter bean； 并以3的硬編碼順序添加了WebSecurityConfigurerAdapter bean。

你為什么要在乎呢？ 因為在更復雜的Web應用程序中，您將要同時使用ResourceServerConfigurerAdapter和WebSecurityConfigurerAdapter來配置權限。 與使用@EnableOAuth2Sso批注時所做的WebSecurityConfigurerAdapter ，這與簡單地使用WebSecurityConfigurerAdapter @EnableOAuth2Sso ，因此我想警告您。 通常，資源服務器端點將以/api或其他內容開頭，并由ResourceServerConfigurerAdapter配置和保護，而其他任何普通HTML端點將由WebSecurityConfigurerAdapter配置。 但是，您需要將@Order(Ordered.HIGHEST_PRECEDENCE)添加到WebSecurityConfigurerAdapter以使其優先于具有硬編碼順序的默認值。

如果要查看如何完成此操作的更具體示例，請查看full-config分支 。 您也可以在最后的鏈接中瀏覽Siva Tech文章。

除了這些，讓我們看一下HelloController類。

@RestController public class HelloController { @RequestMapping("/") public String home(java.security.Principal user) { return "Hello " + user.getName(); } }

@RestController批注是@Controller和@ResponseBody批注的組合。

@Controller告訴Spring Boot此類是控制器類，并查找URL請求到內部方法的映射。

@ResponseBody指示控制器方法返回原始響應數據，并且不映射到模板名稱。 這就是它返回簡單字符串的方式，而不是使用Spring的模型和視圖模板系統。

@RequestMapping("/")表示將home()方法映射到基本URL。

注意使用了依賴注入來獲取java.security.Principal 。 這項工作需要大量自動調整。 Spring和Okta會根據OAuth 2.0和OpenID Connect規范共同驗證令牌并進行來回通信，從而對用戶進行身份驗證并提供JWT授權令牌，該令牌包含具有用戶“名稱”的元數據。

運行Spring Boot App

好的。 一起讓它成為現實！

使用以下命令運行Spring Boot應用程序： ./gradlew bootRun 。

您應該看到很多文本以如下形式結尾：

... [main] INFO org.springframework.jmx.export.annotation.AnnotationMBeanExporter - Registering beans for JMX exposure on startup [main] INFO org.springframework.boot.web.embedded.tomcat.TomcatWebServer - Tomcat started on port(s): 8080 (http) with context path '' [main] INFO com.okta.springboottokenauth.Application - Started Application in 21.209 seconds (JVM running for 21.709) [2018-10-11 10:31:58.646] - 22235 INFO [http-nio-8080-exec-1] --- org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/]: Initializing Spring FrameworkServlet 'dispatcherServlet' [http-nio-8080-exec-1] INFO org.springframework.web.servlet.DispatcherServlet - FrameworkServlet 'dispatcherServlet': initialization started [http-nio-8080-exec-1] INFO org.springframework.web.servlet.DispatcherServlet - FrameworkServlet 'dispatcherServlet': initialization completed in 13 ms

使用JWT進行身份驗證

現在運行Spring Boot應用程序，使用HTTPie運行沒有令牌的GET請求：

http GET http://localhost:8080

您將獲得401 /未經授權：

HTTP/1.1 401 Cache-Control: no-store Content-Type: application/json;charset=UTF-8 ... {"error": "unauthorized","error_description": "Full authentication is required to access this resource" }

重新運行它，這次包括您的令牌（取決于經過了多少時間，您可能需要請求一個新令牌）：

http GET :8080 'Authorization: Bearer eyJraWQiOiJldjFpay1DS3UzYjJXS3QzSVl1...'

提示：如果收到顯示“ Invalid JOSE Header kid”的invalid_token錯誤，則很有可能用不正確的值更新了application.yml 。

假設您的令牌仍然有效，您將獲得一個HTTP 200：

HTTP/1.1 200 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Content-Length: 26 Content-Type: text/plain;charset=UTF-8 ...Hello 0oag58489amZL0MEN0h7

0oag58489amZL0MEN0h7將是您的客戶ID。

請記住，您使用的是client_credentials授予類型，并且已將客戶端ID和客戶端密鑰作為憑據發送給服務器。 因此，授權服務器將您的客戶ID作為您的“名稱”發送回去。 在不同的情況下，例如使用授權碼授予，這將是用戶的名稱（或者可能是他們的電子郵件地址或用戶名）。

了解有關使用Java進行令牌身份驗證和構建安全應用程序的更多信息

了解令牌認證對于構建現代Web應用程序至關重要。 有兩種用于簽名和加密令牌的主要方法：散列和公共/專用密鑰。 兩種方法都是互聯網安全的基礎。 在HMAC上查看Wikipedia頁面 ，以繼續學習JWT中使用的基于哈希的消息認證代碼（HMAC）。 要了解公共/專用密鑰加密， Red Hat進行了出色的介紹 。

一旦您對這兩種技術真正感到滿意，就可以看一下關于Medium的有關JWT的出色教程 。

您可能還需要查看RFC規范 。

在Spring結束時，我發現Siva Tech Lab的本教程對說明如何使用OAuth 2.0實施Spring Boot應用程序很有幫助。

以下是Okta博客的其他一些鏈接，可幫助您繼續前進：

• Spring Boot，OAuth 2.0和Okta入門
• 保護Spring Boot應用程序安全的10種絕佳方法
• 如果您的JWT失竊了怎么辦？
• 使用Spring Boot 2.0和OAuth 2.0構建并保護微服務

如果您對此帖子有任何疑問，請在下面添加評論。 有關更多精彩內容， 請在Twitter上關注@oktadev ， 在Facebook上關注我們，或訂閱我們的YouTube頻道 。

Java Apps的簡單令牌身份驗證最初于2018年10月16日發布在Okta開發人員博客上。

“我喜歡編寫身份驗證和授權代碼。” ?從來沒有Web開發人員。 厭倦了一次又一次地建立相同的登錄屏幕？ 嘗試使用Okta API進行托管身份驗證，授權和多因素身份驗證。

翻譯自: https://www.javacodegeeks.com/2018/10/simple-token-authentication-java-apps.html

認證令牌

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的认证令牌_Java应用程序的简单令牌认证的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。