GitHub の OAuth 実装の仕様違反とセキュリティ上の考慮事項 - Qiita
本稿は GitHub Docs の "Authorizing OAuth Apps" ページに書かれている情報に基づいています。英語版はこちら → "Spec Violations in GitHub OAuth Implementation and Security Considerations" 仕様違反箇所 認可リクエストの response_type リクエストパラメーターがない。当パラメーターは必須である。RFC 6749 (The OAuth 2.0 Authorization Framework) Section 4.1.1 (Authorization Request) 参照。 トークンレスポンスのデフォルトフォーマットが application/x-www-form-urlencoded のようである。フォーマットは常に application/json でなければならな
図解 X.509 証明書 - Qiita
はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
OAuth 2.0 の勉強のために認可サーバーを自作する - Qiita
逆に、RFC 6749 以外で定義されている認可フローをサポートする場合、新たに別のエンドポイントの実装が必要になることがあります。例えば CIBA（Client Initiated Backchannel Authentication）ではバックチャネル認証エンドポイント（backchannel authentication endpoint）、デバイスフロー（RFC 8628）ではデバイス認可エンドポイント（device authorization endpoint）の実装が求められます。 この記事では、認可エンドポイントとトークンエンドポイントを実装します。サポートする認可フローは認可コードフローのみ、サポートするクライアント・タイプはパブリックのみとします。 2. 注意点 下記の理由、および書かれていないその他の理由により、本実装は商用利用には適していません。 セキュリティー上必須
OAuth 2.0 クライアント認証 - Qiita
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
実装者による CIBA 解説 - Qiita
はじめに この記事では、『OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0』、通称『CIBA Core』の解説をおこなう。（CIBA は『シーバ』と読む） OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0 CIBA Core は 2018 年 12 月 14 日に Public Review 期間に入った（アナウンス）。スケジュール通りに進めば、2019 年 2 月初旬には Implementer's Draft として承認される※。 ※：2019 年 2 月 4 日に承認のアナウンスがあった。 Public Review に先立ち、実装者の視点からいろいろ突っ込みを入れておいたので、実装上大
一番分かりやすい OAuth の説明 - Qiita
はじめに 過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。Authlete アカウント登録はこちら！ ※2：そして２回目の資金調達！→『AUTHLETE 凸版・NTTドコモベンチャーズ・MTIからプレシリーズA資金調達』(2018 年 2 月 15 日発表) 説明手順 （１）ユーザーのデータがあります。 （２）ユーザーのデータを管理するサーバーがあります。これを『リソースサーバ
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
