タグ

ブックマーク / qiita.com/TakahikoKawasaki (5)

  • [前編] IDトークンが分かれば OpenID Connect が分かる - Qiita

    はじめに 「解説記事を幾つも読んだけど OpenID Connect を理解できた気がしない」― この文書は、そういう悩みを抱えたエンジニアの方々に向けた OpenID Connect 解説文書です。概念的・抽象的な話を避け、具体例を用いて OpenID Connect を解説していこうと思います。 この文書では、JWS (RFC 7515)、JWE (RFC 7516)、JWK (RFC 7517)、JWT (RFC 7519)、ID トークンの説明をおこないます。 追記(2020-03-20) この記事の内容を含む、筆者人による『OAuth & OIDC 入門編』解説動画を公開しました! 1. 『ID トークン』を発行するための仕様 一般の方々に対しては「OpenID Connect は認証の仕様である」という説明で良いと思います。一方、技術的な理解を渇望しているエンジニアの方々に対

    [前編] IDトークンが分かれば OpenID Connect が分かる - Qiita
  • OAuth 2.0 全フローの図解と動画 - Qiita

    RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記(2020-03-20) この記事の内容を含む、筆者人による『OAuth & OIDC 入門編』解説動画を公開しました! 1. 認可コードフロー RF

    OAuth 2.0 全フローの図解と動画 - Qiita
  • OAuth 2.0 の勉強のために認可サーバーを自作する - Qiita

    逆に、RFC 6749 以外で定義されている認可フローをサポートする場合、新たに別のエンドポイントの実装が必要になることがあります。例えば CIBA(Client Initiated Backchannel Authentication)ではバックチャネル認証エンドポイント(backchannel authentication endpoint)、デバイスフロー(RFC 8628)ではデバイス認可エンドポイント(device authorization endpoint)の実装が求められます。 この記事では、認可エンドポイントとトークンエンドポイントを実装します。サポートする認可フローは認可コードフローのみ、サポートするクライアント・タイプはパブリックのみとします。 2. 注意点 下記の理由、および書かれていないその他の理由により、実装は商用利用には適していません。 セキュリティー上必須

    OAuth 2.0 の勉強のために認可サーバーを自作する - Qiita
  • 一番分かりやすい OpenID Connect の説明 - Qiita

    はじめに 過去三年間、技術者ではない方々に OpenID Connect(オープンアイディー・コネクト)の説明を繰り返してきました※1。 その結果、OpenID Connect をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1:Authlete 社の創業者として資金調達のため投資家巡りをしていました(TechCrunch Japan:『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』)。 2017 年 10 月 23 日:『OpenID Connect 全フロー解説』という記事も公開したので、そちらもご参照ください。 説明手順 (1)「こんにちは! 鈴木一朗です!」 (2)「え!? 当ですか? 証明してください。」 (3)「はい! これが私の名刺です!

    一番分かりやすい OpenID Connect の説明 - Qiita
  • OAuth 2.0 クライアント認証 - Qiita

    サーバーは、受け取ったクライアント証明書の主体識別情報が事前登録されているものと一致することを確認し、もってクライアント認証とします。 このクライアント認証方式には tls_client_auth という名前が与えられています(MTLS, 2.1.1. PKI Method Metadata Value)。 なお、クライアント証明書には OAuth 2.0 の文脈におけるクライアント ID は入っていないので、クライアント証明書だけではクライアントを特定することはできません。そのため、クライアント証明書を用いるクライアント認証をおこなう際は、別途クライアント ID をリクエストに含める必要があります。通常は client_id リクエストパラメーターが使用されます。 1.8. self_signed_tls_client_auth クライアント証明書を用いるクライアント認証において、PKI

    OAuth 2.0 クライアント認証 - Qiita
  • 1