HOME»情報処理安全確保支援士掲示板»令和5年春 午後2 問2 設問4(2)
投稿する
[1463] 令和5年春 午後2 問2 設問4(2)
ふしぎさん(No.1)
クライアントから認可サーバへチャレンジコードを送る時は、検証コードに対してsha256から得られたハッシュ値にbase64urlでエンコードしますよね。
クライアントから認可サーバへ検証コードを送る時は、なぜbase64urlでエンコードしないのですか？
クライアントから認可サーバへ検証コードを送る時は、なぜbase64urlでエンコードしないのですか？
2024.03.30 02:37
wrinklyさん(No.2)
検証コードは、決められた文字種を使った43～128文字のランダムな文字列と
RFC7636で規定されているようです。だから、わざわざbase64urlでエンコード
する必要がないのです。
RFC7636には、32バイトの乱数を生成し、base64urlエンコードで、43文字の
ランダムな文字列を生成する例が載っているそうです。だから、既に
base64urlエンコード済と言えるかもしれません。
上記は、全て
「認証と認可 Keycloak入門」
p192 に書いてあることの受け売りです。
RFC7636で規定されているようです。だから、わざわざbase64urlでエンコード
する必要がないのです。
RFC7636には、32バイトの乱数を生成し、base64urlエンコードで、43文字の
ランダムな文字列を生成する例が載っているそうです。だから、既に
base64urlエンコード済と言えるかもしれません。
上記は、全て
「認証と認可 Keycloak入門」
p192 に書いてあることの受け売りです。
2024.03.30 07:15
ふしぎさん(No.3)
ご回答ありがとうございます。
書籍の名前まだあげていただき、とても参考になります。
ちなみにOauthで一番気になるポイントとして、
この問題ではAuthorizationヘッダにBasic認証を行うためのクライアントIDおよびクライアントシークレットの情報を送っていますが、認可コードフローでは必ず行われるのでしょうか？
それともこのあたりのクライアント認証方式は実装によるものであって、認可コードフローでもBasic認証を行わないものもあるのでしょうか？
書籍の名前まだあげていただき、とても参考になります。
ちなみにOauthで一番気になるポイントとして、
この問題ではAuthorizationヘッダにBasic認証を行うためのクライアントIDおよびクライアントシークレットの情報を送っていますが、認可コードフローでは必ず行われるのでしょうか？
それともこのあたりのクライアント認証方式は実装によるものであって、認可コードフローでもBasic認証を行わないものもあるのでしょうか？
2024.03.30 13:58
GinSanaさん(No.4)
★SC ブロンズマイスター
この投稿は投稿者により削除されました。(2024.03.30 14:34)
2024.03.30 14:34
GinSanaさん(No.5)
★SC ブロンズマイスター
この投稿は投稿者により削除されました。(2024.03.30 19:16)
2024.03.30 19:16
GinSanaさん(No.6)
★SC ブロンズマイスター
rfc7636では
RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
4. Protocol
4.1. Client Creates a Code Verifier
オクテットによる乱数生成器（例えば、/dev/urandomをcatした場合に出てくるものを想像してみてください。出てくるのはバイナリなので、実際には、odやxddでダンプしないとまともに使えないのです。）をBase64urlEncodeしたものなので、実際にはすでにエンコードされたのを使っていることになります。
ABNFの
RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
4. Protocol
4.1. Client Creates a Code Verifier
NOTE: The code verifier SHOULD have enough entropy to make it impractical to guess the value. It is RECOMMENDED that the output of a suitable random number generator be used to create a 32-octet sequence. The octet sequence is then base64url-encoded to produce a 43-octet URL safe string to use as the code verifier.
注: コード検証ツールには、値の推測を非現実的にするのに十分なエントロピーが必要です。 適切な乱数発生器の出力を使用して 32 オクテットのシーケンスを作成することが推奨されます。 次に、オクテット シーケンスが Base64url エンコードされて、コード検証器として使用する 43 オクテットの URL セーフ文字列が生成されます。
「決められた文字種を使った43～128文字のランダムな文字列」を作るときに、オクテットによる乱数生成器（例えば、/dev/urandomをcatした場合に出てくるものを想像してみてください。出てくるのはバイナリなので、実際には、odやxddでダンプしないとまともに使えないのです。）をBase64urlEncodeしたものなので、実際にはすでにエンコードされたのを使っていることになります。
ABNFの
code-verifier = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39
のALPHAやDIGITは一見するとあれBASE64みたいな書き方か？と思いそうですが、ABNFでASCIIの大文字と小文字 (A-Z a-z)と十進数字 (0-9)はそう書くので、エンコードはこの場（Code-Verifier作成）においては発生していません。その手前で用意するときのBASE64は、乱数生成器をSHOULD通りに使うときに必要になる、といっていいと思います。
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39
2024.03.30 19:23
ふしぎさん(No.7)
ご回答ありがとうございます。とても勉強になります。
2024.03.31 16:16