220418 TIL
簡単にTILで勉強記録を残したい一日の勉強でも、キーワードでも、シャベルでも、ゆっくり覚えて、伝言でメモします.間違った内容がたくさんありますハハ
https://opentutorials.org/course/3405
https://www.ietf.org/rfc/rfc6749.txt
先週のプロジェクトでは、JWT(Json Web Token)への応用と学習キーワードがありました.しかし,データベース設計,ドラッグアンドドロップ,交換などの順序変更に多くの時間を費やしたため,適用できなかった. これは面白そうな学習テーマです.
コードを叩いて流れを熟知してみました.flowは実は簡単です.
tokenは,サーバが設定した秘密鍵と暗号化アルゴリズムを用いて符号化し,復号後にJSONデータが含まれていることを確認できる.
クライアントがサーバから送信するtokenはHTTP HEADERに含まれ、クライアントは要求を送信するたびにtokenをHEADERにマウントすることができる.
コインを使うとき、コインを奪われたらどうなりますか?トークンを乗っ取ることができれば,IDやパスワードを知らずに乗っ取るトークンにログインしたユーザのように要求することができる.
これらの問題のため、トークンには
ただし、トークンの有効期間が短くなると、トークンが期限切れになるたびに、ユーザは再ログイン要求を行い、トークンを再発行する必要がある.
必要なのは
リフレッシュトークンを使用すると、ログイン時にEXTAKENとREFRESTAKENがクライアントに同時に発行されます(EXTAKENより有効期間が長い).サーバはrefresh-tokenをDBに格納します.また、エクセストコインが期限切れになった場合、お客様から受け取ったリプレッシュコインを確認し、エクセストを再発行します.
実施ごとに異なりますが、REFRESH TOKENが奪われる危険もあるので、EX TOKENを新たにリリースする際にREFRESH TOKENも再リリースされます.
作成されたコードと
まず上のコードは検証トークンのコードである.try-catchで検証中に発生する可能性のある例外を確認しようとします. 送信要求が任意に変更された場合、は ライフコードのOuth講座を聞き、Outh Flowを観察しました. JWTの流れとよく似ています.トークンの発行や検証の機能は,直接サービスするサーバではなく, は、github tokenが今回のプロジェクトで適用される可能性があります.アプリケーションとテストをして、コードを簡単に整理します.
学習資料
https://opentutorials.org/course/3405
https://www.ietf.org/rfc/rfc6749.txt
緒論
JWT
コードを叩いて流れを熟知してみました.flowは実は簡単です.
tokenは,サーバが設定した秘密鍵と暗号化アルゴリズムを用いて符号化し,復号後にJSONデータが含まれていることを確認できる.
クライアントがサーバから送信するtokenはHTTP HEADERに含まれ、クライアントは要求を送信するたびにtokenをHEADERにマウントすることができる.
コインを使うとき、コインを奪われたらどうなりますか?トークンを乗っ取ることができれば,IDやパスワードを知らずに乗っ取るトークンにログインしたユーザのように要求することができる.
これらの問題のため、トークンには
expiration
、満期時間が含まれます.タグが期限切れになる時間はサーバが独自の基準を設定することができるが,タグが盗まれる危険性があるため,設定を短縮することが望ましい.ただし、トークンの有効期間が短くなると、トークンが期限切れになるたびに、ユーザは再ログイン要求を行い、トークンを再発行する必要がある.
必要なのは
Refresh-token
です以前に発行されたコインはAccess-Token
と呼ばれています.リフレッシュトークンを使用すると、ログイン時にEXTAKENとREFRESTAKENがクライアントに同時に発行されます(EXTAKENより有効期間が長い).サーバはrefresh-tokenをDBに格納します.また、エクセストコインが期限切れになった場合、お客様から受け取ったリプレッシュコインを確認し、エクセストを再発行します.
実施ごとに異なりますが、REFRESH TOKENが奪われる危険もあるので、EX TOKENを新たにリリースする際にREFRESH TOKENも再リリースされます.
作成されたコードと
claim
については、コードをさらに整理して適用し、詳細な整理を行う必要があります.// gradle dependency
runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.2'
implementation 'io.jsonwebtoken:jjwt-api:0.11.2'
runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11.2'
public boolean isValidToken(String token) {
try {
Jws<Claims> claimsJws = Jwts.parserBuilder()
.setSigningKey(secretKey)
.build()
.parseClaimsJws(token);
String subject = claimsJws.getBody().getSubject();
log.info("subject : {}", subject);
} catch (ExpiredJwtException expiredJwtException) {
log.info("token is expired");
return false;
} catch (MalformedJwtException malformedJwtException) {
log.info("token is Malformed");
return false;
} catch (SignatureException signatureException) {
log.info("token is wrong signature");
return false;
}
return true;
}
signatureException
を発行し、要求の有効期間が満了した場合、expiredJwtException
を発行する.malformedException
はまだテストされていませんが、データを携帯していない場合にロードする必要があるcalimが発生する可能性がありますか?OAuth
google
,github
などのサーバによって処理されると考えられる. +--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
Reference
この問題について(220418 TIL), 我々は、より多くの情報をここで見つけました https://velog.io/@cmsskkk/220419-TILテキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol