いまどきの OAuth/OIDC 一挙おさらい (2020 年 1 月) - Authlete
2012 年に OAuth 2.0 (RFC 6749 / 6750)、2014 年に OIDC 1.0、そして 2015 年に PKCE (RFC 7636) / JWT (RFC 7519) がそれぞれ標準仕様となり、いまでは多方面に活用されるようになりました。一方で 2015 年以降も、さまざまな OAuth 2.0 拡張仕様が登場し、さらに OAuth 2.0 / OIDC 適用のプラクティスも改良されています。 もしかしたら、数年前には標準が存在せず独自拡張を試みるしかなかったユースケースに、いままさに策定中の仕様が活用できるかもしれません。あるいは、以前は最良であると考えられていた OAuth 2.0 適用の定石も、いまでは時代遅れになっているかもしれません。 今回の勉強会では、主に「ポスト PKCE / JWT（2015 年以降）」を中心に、Authlete 社の独断と偏見に
Authlete 以外のシステムが発行したアクセストークンの移行 - Authlete
Authlete 以外のシステムが発行したアクセストークンの移行 はじめに 既存の認可サーバーシステム（旧システム）を Authlete に移行する場合、旧システムが過去に発行したアクセストークンをどのように取り扱うかを検討する必要があります。 もしリソースサーバーが、旧システムが発行したか、Authlete が発行したかによらず、クライアントから受け取ったアクセストークンの検証（イントロスペクション）を全て Authlete に依頼するのであれば、Authlete は旧システムのアクセストークンの情報も管理しなくてはなりません。 本記事では、Authlete 以外が発行したアクセストークン情報を Authlete に移行する方法を紹介します。 移行方法 Authlete のトークン管理 API のひとつである /auth/token/create API を用います。この API によっ
オープンバンキング/API 勉強会を開催いたしました - Authlete
2019 年 9 月 27 日、電子決済等代行事業者協会主催、弊社後援にて、『オープンバンキング/API 勉強会』と題したイベントを開催し、数多くの金融関係者の方にご参加いただき、大変ご好評いただきました。 以下、参考資料を共有させていただきます。 第1部：報告書 “Open Banking: Preparing for Lift Off” のご紹介 (マネーフォワード社） Open Banking Report 2014年の HMT レポート カスタマーエクスペリエンスガイドライン CMA のレポートの解説（マネーフォワード Fintech 研究所ブログ） 英オープンバンキングの進捗レポート（マネーフォワード Fintech 研究所ブログ） 第2部：英国オープンバンキング技術仕様の概要（Authlete 社） 今後も定期的にイベントを開催の予定です。connpass 内の Authlet
トークンに任意のプロパティをひもづける方法 - Authlete
プロパティをクライアントから秘匿するか否かを示すフラグ。true の場合には秘匿する。false の場合には秘匿しない（クライアントに露見する）。 たとえば、キーが example_key、値が example_value であり、クライアントから秘匿しない（クライアントへの露見を許容する）プロパティは、以下のような JSON オブジェクトになります。 { "key": "example_key", "value": "example_value", "hidden": false } プロパティのひもづけ アクセストークンへのプロパティのひもづけは、下記のタイミングで行います。 認可サーバーが「認可エンドポイント」から認可コードもしくはアクセストークンを返却する直前 認可サーバーが /auth/authorization/issue API を呼び出す際にプロパティをセットします。 以下
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
