こんにちは、サイオステクノロジー技術部 武井(Twitter:@noriyukitakei)です。今回は、OpenID Connectをなるべくわかりやすく書きたいと思います。OAuthと同様、このOpenID Connectもなかなかに難解なプロトコルです。そんなOpenID Connectをご理解頂くためのきっかけになれればと思います。 ※ OpenID ConnectのベースとなるOAuthの記事も合わせて参考にして頂ければ幸いです。 多分わかりやすいOAuth ※ その他OpenID Connectの記事の一覧は以下のリンクをクリックすればご覧になれます。 OpenID Connect関連の記事一覧 OpenID Connectとは？ OpenID Connectは、OAuthのフローをベースにしており、本来、クライアント側で行っていた認証処理を、他のサーバー(OpenID Pro
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
おはようございます、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 は 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_ty
PKCE とは PKCE をご存知でしょうか？ これは、今から一年ほど前の 2015 年 9 月に RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients) として公開された仕様を指しています。認可コード横取り攻撃 (authorization code interception attack) への対策として策定されました。 細かい条件は幾つかありますが、スマートフォンで OAuth クライアントを作る場合は、クライアント側も認可サーバー側もこの仕様の実装が強く推奨されます。これを実装しておかないと、悪意のあるアプリケーションに認可コードを横取りされてしまい、結果、悪意のあるアプリケーションがアクセストークンを取得できてしまいます。 この仕様自体のちょっとした解説は、「OAuth & OpenID Connect 関連仕
始めに様々なシステムを構築する中で必ず発生する要素 ログイン そのログインを支える技術要素 認証・認可 しかし、認証認可の壁は無駄に高く、調べ始めるとまずは数々の専門用語に阻まれ BASIC認証・OAtuh・OpenID・Jwt・Jwk・Jwe… 次に、認証Flowに阻まれます。 Implicit Flow、Client Credentials Flow…etc これらを比較的容易に実装する、Auth0を紹介していきます。 なぜ今回の連載がAuth0なのか？社内で以下の要件を持つ案件が複数あり、結果としてそれぞれでAuth0を採用・知見が溜まったため、連載という形をとることにしました。 OIDC(OpenIdConnect)準拠の要件 Google/Facebookなどのソーシャル連携の要件 開発の期間が短い メンテナンス費用は抑えたい 認証認可の実現方式とAuth0の立ち位置実現方法は大
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 過去三年間、技術者ではない方々に OpenID Connect（オープンアイディー・コネクト）の説明を繰り返してきました※1。 その結果、OpenID Connect をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。 2017 年
長年、組織領域とインターネット領域の境界で高価なセキュリティ製品を配備し、脅威から資産を守る手法が、世の中のデファクトスタンダードとして、多くの企業で採用されてきました。しかし、「モバイルデバイスの活用」、「クラウドサービス利用の浸透」、「ワークスタイルの変革」などのリクエストによって、その有効性は失われつつあります。また、これらのリクエストに対し、資産ごとにセキュリティ対策を実施すると、コストが非常に高くなる傾向があります。 第一回の本記事では、資産を守るための新たな境界である「アイデンティティ」に注目し、その境界を体現する認証連携方式について解説を行います。そして、数ある認証連携方式の中から2014年2月に標準化された「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
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く