タグ

openidに関するdonotthinkfeelのブックマーク (9)

  • OAuth 2.0 / OIDC 実装の新アーキテクチャー - Qiita

    1.『On-Premises』パターンは、自分でマシンを用意し、そこに認可サーバーのソフトウェアをインストールして運用する方法です。 2.『Hosted Server』パターンは、マシンの物理的な運用はクラウドサービスにまかせ、そのマシン上に認可サーバーのソフトウェアをインストールして運用する方法です。 例えば AWS の EC2 インスタンスに OpenAM をインストールして運用する場合、このパターンに該当します。 3.『Hosted Service』パターンは、認可サーバー自体がクラウドサービスとして提供されるパターンです。 Okta や Auth0 がこのパターンに該当します。 4.『Semi-Hosted Service』パターンは、認可サーバーの主要機能を提供するサーバーが存在するものの、一部をローカルで実装するというパターンです。 Richer 氏が明示的に言及しているように

    OAuth 2.0 / OIDC 実装の新アーキテクチャー - Qiita
  • 【第二弾】OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る

    はじめに 記事は「OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る」の続編となります。保護リソースエンドポイント (protected resource endpoint)、いわゆる世の中でいうところの (狭義の) Web API の実装に関する話題がメインとなります。 1. もう一つの認可 1.1. アカウント属性文脈での認可 混乱を避けるため前記事では敢えて言及しませんでしたが、認可という言葉は別の文脈で使われることがあります。その文脈では、「誰が何の権限を持っているか (who has what permissions)」という情報を扱うために認可という言葉を使います。これは、OAuth の文脈での認可「誰が誰に何の権限を与えるか (who grants what permissions to whom)」とは異なります。厄介なことに、このど

    【第二弾】OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
  • Identity Assurance - eKYC 時代の OpenID Connect - Qiita

    はじめに 2018 年 11 月 30 日に『犯罪による収益の移転防止に関する法律』(犯罪収益移転防止法/犯収法)を改正する命令が公表されました。この改正で「オンラインで完結する自然人の人特定事項の確認方法の追加」が行われ、eKYC(electronic Know Your Customer)の根拠法となりました。 そして、当改正から約一年後の 2019 年 11 月 11 日、世界標準仕様策定団体である OpenID Foundation から『OpenID Connect for Identity Assurance 1.0』という技術仕様の第一版が公開されました。また、これを受けて同団体内に新たに『eKYC and Identity Assurance ワーキンググループ』が設置されました。それから約半年後の 2020 年 5 月 19 日には、同仕様の第二版が公開されました。 犯

    Identity Assurance - eKYC 時代の OpenID Connect - Qiita
  • [前編] 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
  • 一番分かりやすい 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
  • OpenID Certification Program が2018年EIC賞を受賞しました

    【ミュンヘン 5月17日】OpenID Connect の実装が、仕様に準拠しているかどうかを確認するためのツールであるOpenID Certificationプログラムが、Identity界でのもっとも権威ある賞、『2018年European Identity and Cloud Award (EIC賞)』の「ベスト・イノベーション賞」を受賞しました。(詳細はこちら) OpenID Certification Programが属するAB/Connect WGの共同議長達 (左)ブラッドレー氏 [共同議長] (中央)プログラムのリードであるジョーンズ博士 [共同議長] (右)筆者 [議長] (写真上)ウメオ大学(写真下右)ヘドバーグ研究員の研究室(写真下左)このときのホワイトボードの一部 OpenID Certification Program の端緒は、「総務省 平成24年度 戦略的国

    OpenID Certification Program が2018年EIC賞を受賞しました
  • アプリ開発で知っておきたい認証技術 - OAuth 1.0 + OAuth 2.0 + OpenID Connect -

    アプリケーション開発エンジニアが、OAuth 1.0 や OAuth 2.0、および OpenID Connect を活用したユーザ認可と認証機能を実装するにあたって、いろいろ調べた情報をベースに作成したものです。 これから認可・認証技術を学びたいという、特にアプリ開発エンジニアの助けになれば幸いです。

    アプリ開発で知っておきたい認証技術 - OAuth 1.0 + OAuth 2.0 + OpenID Connect -
  • OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る

    はじめに この文書では、OAuth 2.0 + OpenID Connect サーバーをゼロから一人で実装した開発者(私)が、得られた知見について書いていきます。基的には「実装時に考慮すべき点」を延々と述べることになります。 そのため、この文書は、「素早く OAuth 2.0 + OpenID Connect サーバーを立てる方法」を探している方が読む類のものではありません。そのような情報をお求めの方は、「Authlete を使って超高速で OAuth 2.0 & Web API サーバーを立てる」を参照してください。そちらには、「何もない状態から認可サーバーとリソースサーバーを立て、アクセストークンの発行を受けて Web API をたたいて結果を得る」という作業を、所要時間 5 ~ 10 分でおこなう方法が紹介されています。 文書のバイアスについて 私は、OAuth 2.0 + Ope

    OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
  • OpenID Connect リリース~インターネットのアイデンティティ層

    苦節4年半、ワーキンググループを作るところから始めたら、苦節6年、ようやくOpenID Connectをリリースしました。 OpenID Connect は、インターネット上の「アイデンティティ層」をなすものです。ちょっと説明しましょう。 レイヤーとか「層」とかというと、よく使われるものTCP/IPの参照モデルというものがあります[1]。これはIETFによって策定された、インターネット上のホストの持つべき通信機能を階層構造に分割したモデルで、TCP/IP参照モデル、インターネット・プロトコル・スイートなどとも呼ばれ、通信機能(通信プロトコル)を4つの階層に分けて定義しています(RFC1122)。この第4層はアプリケーション層と呼ばれますが、これは、あくまでHTTPやFTP等の通信サービスのことであり、いわゆる「業務アプリケーション」の意味ではありません。実際のユーザが使う「業務アプリケーシ

    OpenID Connect リリース~インターネットのアイデンティティ層
  • 1