多分わかりやすいOpenID Connect – SIOS Tech. Lab
◆ Live配信スケジュール ◆ サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。 ⇒ 詳細スケジュールはこちらから ⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください 【6/19開催】Kong Community Japan Meetup #4 本イベントでは、Kong Inc. のVP of ProductであるReza Shafii氏もプレゼンターとして参加。当社からはアーキテクト マネージャーの槌野の登壇が決定！参加無料です!! https://column.api-ecosystem.sios.jp/connect/kong/1081/ 【6/21開催】開発者目線でのSBOMとの向き合い方 SBOMの導入から開発者がSBOMの作成・管理を自動で行っていくための方法（デモ）を紹介します。
OpenID Connectのフローや、JWKやPKCEについて解説
2020年3月17日、株式会社Authleteが主催する「OAuth & OIDC 勉強会 リターンズ【入門編】」が開催。同社の共同創業者であり、プログラマー兼代表取締役でもある川崎貴彦氏が、OAuth 2.0 / OIDCの仕様について解説しました。本記事では、OpenID ConnectのフローやJWKとIDトークンの関係、セキュリティ的に非常に重要かつ必須なPKCEについてわかりやすく解説していきます。 OAuth 2.0フローとOpenID Connectフローとの関係 川崎貴彦氏：今度はOpenID Connectのフローの説明をします。 OAuth 2.0では認可エンドポイントを使うフローとして、認可コードフローとインプリシットフローの2つがあります。認可コードフローの認可リクエストとインプリシットフローの認可リクエストは、どうなっているかというと、まずresponse_typ
そのIDTokenの正体はセッショントークン？それともアサーション？ - r-weblife
おはようございます、ritouです。 今年も Firebase Authentication や Auth0 とか沢山使われると思いますが、去年からよく聞かれる件をざっくりと書いておきます。 ID Tokenってセッショントークンとして使っていいんですよね？ 例えばこちらの記事を見てみましょう。 Google の ID Token をセッショントークンとして使おうとして断念 techblog.kayac.com 認証は Google の OpenID Connect の Auth Code Flow による認証を採用しています。ユーザと Google 間の認証後の callback で code を受け取り、code exchagne で ID token を取得します。 Google ID token は以下のような Google アカウントのユーザ情報を含む JWT です。 これはいわ
OpenID Connect 全フロー解説 - Qiita
はじめに OpenID Connect は OAuth 2.0 を拡張する形で策定されました。 OAuth 2.0 はアクセストークン発行手順に関する仕様で、RFC 6749（The OAuth 2.0 Authorization Framework）で定義されています（参考：一番分かりやすい OAuth の説明）。 一方、OpenID Connect は ID トークン発行手順に関する仕様で、主要部分は OpenID Connect Core 1.0 で定義されています（参考：一番分かりやすい OpenID Connect の説明）。 RFC 6749 は認可エンドポイントという Web API を定義しています。 この API は必須のリクエストパラメーターとして response_type を要求します。 OpenID Connect は、この response_type の仕様を拡
PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと - Qiita
PKCE とは PKCE をご存知でしょうか？ これは、今から一年ほど前の 2015 年 9 月に RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients) として公開された仕様を指しています。認可コード横取り攻撃 (authorization code interception attack) への対策として策定されました。 細かい条件は幾つかありますが、スマートフォンで OAuth クライアントを作る場合は、クライアント側も認可サーバー側もこの仕様の実装が強く推奨されます。これを実装しておかないと、悪意のあるアプリケーションに認可コードを横取りされてしまい、結果、悪意のあるアプリケーションがアクセストークンを取得できてしまいます。 この仕様自体のちょっとした解説は、「OAuth & OpenID Connect 関連仕
Auth0 導入編 | フューチャー技術ブログ
始めに様々なシステムを構築する中で必ず発生する要素 ログイン そのログインを支える技術要素 認証・認可 しかし、認証認可の壁は無駄に高く、調べ始めるとまずは数々の専門用語に阻まれ BASIC認証・OAtuh・OpenID・Jwt・Jwk・Jwe… 次に、認証Flowに阻まれます。 Implicit Flow、Client Credentials Flow…etc これらを比較的容易に実装する、Auth0を紹介していきます。 なぜ今回の連載がAuth0なのか？社内で以下の要件を持つ案件が複数あり、結果としてそれぞれでAuth0を採用・知見が溜まったため、連載という形をとることにしました。 OIDC(OpenIdConnect)準拠の要件 Google/Facebookなどのソーシャル連携の要件 開発の期間が短い メンテナンス費用は抑えたい 認証認可の実現方式とAuth0の立ち位置実現方法は大
一番分かりやすい 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 全フロー解説』という記事も公開したので、そちらもご参照ください。 説明手順 （１）「こんにちは！ 鈴木一朗です！」 （２）「え！？ 本当ですか？ 証明してください。」 （３）「はい！ これが私の名刺です！
第一回 認証基盤のこれからを支えるOpenID Connect | オブジェクトの広場
長年、組織領域とインターネット領域の境界で高価なセキュリティ製品を配備し、脅威から資産を守る手法が、世の中のデファクトスタンダードとして、多くの企業で採用されてきました。しかし、「モバイルデバイスの活用」、「クラウドサービス利用の浸透」、「ワークスタイルの変革」などのリクエストによって、その有効性は失われつつあります。また、これらのリクエストに対し、資産ごとにセキュリティ対策を実施すると、コストが非常に高くなる傾向があります。 第一回の本記事では、資産を守るための新たな境界である「アイデンティティ」に注目し、その境界を体現する認証連携方式について解説を行います。そして、数ある認証連携方式の中から2014年2月に標準化された「OpenID Connect」に注目して、仕様説明と有用性を解説したいと思います。 認証基盤のこれまで 認証基盤における認証対象アプリケーションとの連携実装方法を振り返
これからのネイティブアプリにおけるOpenID Connectの活用
タイトル： 『これからのネイティブアプリにおけるOpenID Connectの活用』 概要： 近年モバイルアプリケーションの多くはログインを必須としています。自社他社提供のWeb APIの利用にあたりクライアントサイド、サーバーサイドのそれぞれにおいて認証の仕組みを理解し、正しい認証の実装が求められます。 本セッションではユーザーとデバイスの2つの視点でモバイルにおける認証をご紹介します。 ユーザー認証のパートでは、OAuth 2.0ベースのID連携の問題点に触れ、その課題を解決するためのOpenID Connectの仕様について解説します。 デバイス認証のパートでは、スマートフォンやタブレットを識別するための仕様の解説と活用方法について解説します。 Developers Summit 2014 【13-C-5】 Feb. 13, 2014 URL: https://event.shoei
Final: OpenID Connect Core 1.0 incorporating errata set 2
Abstract OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. This specification defines the core OpenID Connect functionality: authenticatio
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
