Open2
auth0
qatoco
| Oauth2 | 認可のフレームワーク |
| OIDC | Oauth2の拡張。認証のプロトコル |
| SAML | プロトコル。SSO用として普及 |
| WS-Federation | SAML競合 |
| SSO | "ユーザーが中央サーバーで一 度認証を行った後、すべてのアプリケーションはこの一元化されたサービスによ って提供されるアイデンティティを信頼します。" |
| by-referenceトークン | cookieベースの認証で使われる |
| by-value トークン | トークンベースの認証というときはこっちが念頭にある。JWTとか |
| 自己完結型であるトークン | "トークンの 値自体の中にエンティティ、トークンの対象に関する情報が含まれている"。"ステートレスな認証システムを構築するシナリオで は、理想的" |
| JWTのエンコード | base64urlエンコーディングが主流。暗号化トークンは稀 |
| TLS必須のプロトコル | OAuth2, OIDC |
| SAMLトークンフォーマット | JWT以前では普及。XMLベース |
| トークンのタイプ | アクセストークン、リフレッシュトークン、IDトークンetc |
| アクセストークン | OAuth2仕様で定義。認可完了後に付与される。Bearerトークンとして使われる |
| アクセストークンのフォーマット | 仕様上の要件なし。自己完結型トークンが一般的。"ークンに関連付けら れている情報を取得するためにリソースサーバーが認可サーバーに追加の呼び 出しをする必要がないため" |
| アクセストークンを認証手段として使うことへの懸念 | "たとえば、アクセストークンがベンダー AのAPI Xに発行され、ベンダーBのアプリケーションYがそのアクセストークンを アプリケーション自体のユーザー認証にも使用すると決めた場合、そのアクセス トークンがそれ自体によって開始された認可フローで発行されたのか、それとも アクセストークンを使ってユーザーになりすまそうとしているハッカーの制御下で全く関係のないアプリケーションに対して発行されたのかをアプリケーション は確認することができません。" |
| リフレッシュトークン | OAuth2に仕様定義されてる |
| IDトークン | OIDCの仕様で定義された。JWT必須。 |
qatoco
-
authentication: Bearer xxxxの仕様 - Bearerトークン = 署名なしトークン
- トークンの所有者は、トークンがvalidである限りは保護されたリソースへアクセスできる、とする考え
クライアントが署名無しトークンを伴う認証されたリクエストを送信する際には, Bearer HTTP認可スキームを用いたAuthorizationリクエストヘッダフィールドを使用すべきである (SHOULD). リソースサーバはこの方法をサポートしなければならない (MUST).
OAuth2の仕様ではmultipart/form-data ではアクセストークンは送信できない
- application/x-www-form-urlencoded
- "HTTPリクエストのエンティティボディがシングルパートである."
-
access_tokenパラメータ で送る - request bodyが使えるメソッド限定
URLにアクセストークン埋め込むことは非推奨
現在利用されていることからドキュメントに含まれている. セキュリティ上の重大な不備 (Section 5参照) のため, 利用は非推奨
- application/x-www-form-urlencoded で送るか、Authorizationヘッダを使うべき