Linux Daily Topics Linux Foundation、OpenID Connectを拡張した暗号化プロトコル「OpenPubkey」をローンチ Linux Foundationは10月4日（米国時間）、BastionZeroおよびDockerとともに暗号化プロトコルのオープンソースプロジェクト「OpenPubkey」をローンチすることを発表した。 Linux Foundation, BastionZero and Docker Announce the Launch of the OpenPubkey Project -linuxfoundation.org The Linux Foundation, BastionZero and Docker are excited to announce the launch of OpenPubkey as a Linux
「最高にエモい」と好評だったOpenID Summit Tokyoクロージング・キーノート 「No ID, No DX」の録画が一般公開されました
３年前のOpenID Summit Tokyo で「最高にエモい」と好評だった OpenID Summit Tokyo のクロージング・キーノートの録画が公開されました。 本編スタートは 06:18 から。将来と希望ということから話を始め、産業革命の本質と大英帝国成立の背景を説明、そこから得られる第４次産業革命への示唆とサイバー大陸＝第八大陸の成立とアップル教皇国、フェイスブック王国、グーグル共和国、WeChat人民共和国など列強(#GAFAM)による #第八大陸分割、#DFFT による経済成長についてのEUの見解、#eID #trustservices #eIDAS の意義、そして戦わない楽な道＝ #西用 路線をとることによる植民地化と貧困への道と、 #変法 による希望のもてる将来の話をしています。 ３年前のスピーチですが、今でも全く古びていないと思います。いやむしろ、 #web3 で分
この記事は下書き段階です。記事の執筆途中であるため、内容が不完全である可能性があります。 最後まで執筆が完了していないため、内容が変更される可能性があります。また、誤りを含んでいる可能性がありますので、ご了承ください。 すべての執筆が終わった後、内容の正しさを確認した上で、別の記事として公開する予定です。 はじめに こんにちは。calloc134 です。 就活シーズン真っ最中。つらみ。 執筆が終わる前に就活が終わりました ・・・笑 ここ最近、OAuth と OIDC について調べていました。 その際、なかなか躓くところが多く、学習に苦労したため、個人的に疑問に思ったことをベースに、OAuth と OIDC のフローについて解説していきたいと思います。 この記事を書くにあたり、ritou さん・Auth 屋さんの記事や書籍を参考にさせていただきました。 また、この記事を書くにあたり、rito
curlでKeyless Signingする (1) - OpenID Connect編 - knqyf263's blog
確実に忘れるであろう将来の自分と、Keyless Signingに異常な興味を持つ日本に数人しかいないであろう人達のための記事です。 背景 前提 Keyless Signing全体のフロー OIDCのフロー 認可コードの取得 IDトークンの取得 手動で試す OpenIDプロバイダーの情報取得 認可コードの取得 code_verifierの生成 code_challengeの生成 Authorization Endpointへのアクセス IDトークンの取得 IDトークンの検証 公開鍵の取得 公開鍵の生成 検証 参考 まとめ 背景 以前sigstoreのソフトウェア署名についてブログを書きました。 knqyf263.hatenablog.com その中でKeyless Signingについては別ブログにすると言っていたのですがサボり続けた結果、全て忘れ去り再び調べる羽目になりました。これはまた
GitHub - ory/kratos: Headless cloud-native authentication and identity management written in Go. Scales to a billion+ users. Replace Homegrown, Auth0, Okta, Firebase with better UX and DX. Passkeys, Social Sign In, OIDC, Magic Link, Multi-Factor Auth, SMS
The Ory Network is the fastest, most secure and worry-free way to use Ory's Services. Ory Identities is powered by the Ory Kratos open source identity server, and it's fully API-compatible. The Ory Network provides the infrastructure for modern end-to-end security: Identity & credential management scaling to billions of users and devices Registration, Login and Account management flows for passkey
FAPIとKeycloakの概要
連載の1回目である今回は、FAPIの概要並びに、IAMのKeycloakのFAPI対応について紹介します。 はじめに サービスデリバリのアジリティを高めるために、今やサービス開発にAPIを利用することは必要不可欠となっています。また既存サービスに新たな価値を付与するために、APIを公開することも常套手段の一つとなっています。このようにAPIに触れる機会が日常にあふれている一方、APIに対して適切なセキュリティ設計を行わなかったために、機密性の高い情報が漏えいしてしまったり、金融取引に関わる不正操作を許してしまったりという事故や事件は後を絶ちません。攻撃者による攻撃が日々進化をし続けている中、APIを公開するシステムに求められるセキュリティ要件は日々高度化しています。 そんな中で注目を集めているのが、Financial-grade API Security Profile（以下、FAPI）で
GitHub - hashicorp/cap: A collection of authentication Go packages related to OIDC, JWKs, Distributed Claims, LDAP
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
GitHub ActionsからAWSを操作できると便利です。OIDC（OpenID Connect）を使えばアクセスキーも不要で、セキュアに運用できます。しかし複数システムにまたがる特性上、トラブルシューティングは面倒です。そこで本記事ではトレーサビリティを向上させ、メンテナンスしやすくする手法を紹介します。トレーサビリティが向上すれば、運用はもっと楽になります。 GitHub ActionsとAWSは赤の他人 当たり前ですが、GitHub ActionsとAWSはまったく異なるシステムです。何を言っているんだという感じですが、トレーサビリティの観点では重要です。なぜなら複数のシステムを扱うときは、トレースできるよう設計しないとトレーサビリティは生まれないからです。 GitHub ActionsやAWSに限らず、普通は他所様のシステムなど知ったこっちゃありません。このお互いに知らんぷりを
【連載】世界一わかりみの深いOAuth入門 〜 その1:OAuthってなに？ 〜 | SIOS Tech. Lab
以下のユースケースを考えてみます。Twitterにつぶやくと、自動的にそのつぶやきがFacebookにも反映される仕組みです。 ID・パスワード認証の場合それでは先のユースケースをID・パスワード認証の場合どのように行われるかを見ていきます。 TwitterのシステムにAさんのFacebookのユーザーID、パスワードを登録します。 Aさんがつぶやきます。 Twitterのシステムに登録されているFacebookのユーザーID・パスワードを元にFacebookに接続します。 TwitterがユーザーAさんの代わりにFacebookに投稿します。 このしくみは、大きな弱点があります。TwitterにはAさんのFacebookのユーザーID・パスワードが登録されています。Twitterを運営している人に悪い人がいて、その人がAさんのFacebookのID・パスワードで勝手にFacebookに接
Railsとdoorkeeper-openid_connectやOmniAuth を使って、OpenID Connectの OpenID Provider と Relying Party を作ってみた - メモ的な思考的な
OAuth2やOpenID Connectの理解を深めようと思い、 OAuth徹底入門 セキュアな認可システムを適用するための原則と実践（Justin Richer Antonio Sanso 須田 智之 Authlete, Inc.）｜翔泳社の本 Auth屋さんの書籍 【電子版】雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本 - Auth屋 - BOOTH 【電子版】OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本 - Auth屋 - BOOTH 【電子版】OAuth・OIDCへの攻撃と対策を整理して理解できる本（リダイレクトへの攻撃編 - Auth屋 - BOOTH OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife OAuth & OpenID Connect 関連仕
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに OAuth 2.0 の認可レスポンスは、登録済みの『リダイレクト URI』宛に返却されます。詳細は『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』を参照してください。 複数のリダイレクト URI が登録されている場合、どのリダイレクト URI に認可レスポンスを返して欲しいかを、認可リクエスト時に指定する必要があります。この目的のために、redirect_uri リクエストパラメーターが用いられます。 認可サーバーは、redirect_uri リクエストパラメーターで指定された URI が、事前登録されたリダ
Messaging technologies have exploded in popularity in recent years. The broad usage of messaging as a framework, especially in distributed systems, requires a dedicated and standardized approach to security. One possible solution to the problem of standards-based secure messaging is to build on top of a family of pre-existing security technologies known as JOSE. JSON Web Message (JWM) is a draft s
OpenID Connectとは 用語 OpenID Connectを試してみる OP側の準備 - AWS Cognito ユーザープールと最初のクライアントを作成する 作成されたパラメータを確認する ディスカバリ ユーザープールにユーザを追加する RP側の準備 - Pythonアプリ 実施 認証の流れ ログインする トークンをリフレッシュする トークンを失効させる ログアウトする IDトークンの形式 サンプルコード リンク OpenID Connectとは SSO(シングルサインオン)を実現するプロトコルのひとつです。 例えば、食べログ に Google アカウントでログインすることができますが、ここでも OpenID Connect が使用されています。 OIDC と略されることもあります。 類似の仕様に OpenID 2.0 がありましたが、OpenID 2.0 の進化系が Open
【連載】世界一わかりみの深いOAuth入門 〜 その2:アクセストークンとリフレッシュトークン 〜 | SIOS Tech. Lab
こんにちは、サイオステクノロジー武井です。今回は、ちょっと難解なOAuthをわかりみ深く説明してみたいと思います。本記事は、私がOAuthを理解するまでの備忘録みたいなものになり、説明が至らないこと多々あると思いますが、生暖かい目で見守って頂けますと幸いです。 全4回シリーズでお届けする予定で、今回は第2回目となります。 その1：OAuthってなに？ 今回はこちら → その2：アクセストークンとリフレッシュトークン その3：OAuthを認証に使うことの危険性 その4：stateパラメーターによるCSRF対策 アクセストークンとは？ 今回は、「その1：OAuthってなに？」であげたOAuthの4つの特徴のうち、以下の2つ(3と4)を説明致します。 従来のID・パスワードベースとは異なるトークンベースの認証 トークンには限られた権限だけを与えられているので、万が一トークンが盗まれても被害が少な
Webの世界を大きく変えるかもしれない分散ID標準規格「DIDs」についてえーじさんに聞いてみました。 Web技術の標準化団体「World Wide Web Consortium(W3C)」は7月19日、分散IDの標準規格「DIDs(Decentralized Identifiers)」のv1.0を勧告しました。この勧告をきっかけに、DIDsだけではなく、Web3やWeb5と呼ばれる非中央集権的なWeb世界やその要素技術であるブロックチェーンへの関心が高まっています。一方で、これまでのいわゆる中央集権的なWebの世界で使われてきたID管理とDIDsは何が異なるのか、一般の人々にはまだあまり理解が浸透していないようです。 DIDsが標準規格となったことで、Webの世界にはどんな影響があらわれるのか - 今回の「Ask the Expert」ではWebの標準技術に精通したエキスパートのえーじ(
セッションのアジェンダ武井宜行氏：こんにちは。SIOS PS Liveの第1回目を始めます。SIOS PS Liveでは、サイオステクノロジーのプロフェッショナルサービスラインのエンジニアたちが、隔週に渡っていろいろな技術情報を提供していきます。 弊社は認証、特にプロフェッショナルサービスラインは認証技術を得意としている部署なので、第1回目は「OAuthの入門」と題して、「世界一わかりみの深いOAuth入門」について説明したいと思います。さっそく始めます。 基本的には、OAuthに初めて触れる人に向けたセッションです。序章はOAuthをざっくり説明、第2章は認可コードフローやImplicitインプリシットフローなどといった、いろいろなフローです。第3章はリフレッシュトークン、第4章はアクセストークンです。第5章はOAuthを認証に使うことの危険性。第6章はstateパラメータによるCSRF
「パスキーのすべて」という本を書きました
「パスキーのすべて」という本を書きました。1 月 28 日に発売する本書の内容について軽く紹介します。 パスキーのすべて 「パスキーのすべて」は米国 OpenID Foundation 理事、OpenID ファウンデーション・ジャパン KYC WG リーダの小岩井さんと、OpenID ファウンデーション・ジャパン 理事・エバンジェリストのくらと一緒に書きました。小岩井さんとは昨年開催したパスキーハッカソンでもご協力頂きましたし、同じイベントで登壇する機会も多く、最近 FIDO 関連に限らず色々とお世話になっています。くらとはもう 10 年以上、ID 界隈のコミュニティで仲良くしてもらっています。二人共気の置けない愉快な仲間たちです。大まかに分担はしましたが、全員が全体に責任を持つという体制で執筆を行い、終盤は何度かみんなで技術評論社の会議室に篭って執筆・レビューするなど、作業そのものを楽し
概要 クライアント↔サーバ間の認証・認可情報としてのトークン管理はWebサービスとしては必ずつきまとうものですが、一方できちんと実装しないとセキュアに管理はできません。 今回はそのトークン管理方法の一例を紹介します。 要件 今回の主な要件は以下です。 AuthサーバとResourceサーバは別で管理する（負荷特性が異なるので） 認証するとAuthサーバはrefresh tokenとaccess tokenを返す access tokenはJWT形式 access tokenはクライアントのオンメモリで管理する access tokenの期限は短く（１時間以内） refresh tokenを使ってaccess tokenを発行できる refresh tokenはrevoke可能である 認証情報に変更があれば（パスワード変更など）refresh tokenをrevokeできる Resource
※この記事は別アカウント(hyiromori)から引っ越しました はじめに 最近、個人的に認証認可周りを学習していて、今回は OpenID Connect について学習したのでその内容をまとめた記事です。 世の中には既に OpenID Connect に関する優れた書籍やブログ記事が沢山ありますが、自分が学習する過程で色々なものを読むことでより理解が深まったと思うので、自分も学習したものをアウトプットすることで同じように学習している人の理解の助けになればと思い書きました。 まだ私も学習中なので、もし間違ったところなどあればコメント頂けるとありがたいです。 OpenID Connect とはなにか？ OAuth2.0をベースにして（認可だけでなく）認証も行えるようにした拡張仕様です。 なぜOAuth2.0が認証に使えないかというと、以下のように認証に使ってしまうとリスクが非常に高いからです。
Digital Identity技術勉強会 #iddance - Qiita Advent Calendar 2020 - Qiita
2020年になりすっかりなりを潜めていますが、DigitalIdentityに関する技術の勉強会である #iddance のアドカレやります。 参加条件は自由です。いわゆる認証認可と関連する技術、OAuth、OpenID Connect、FIDO、WebAuthn、DID、SSI、eyJ(JWT)、そしてSAMLとかに興味のある人、一緒に何か書きましょう！プロトコルや仕様に縛られずいろいろな話題が集まることを期待しています。 「書いてみたいけどお前やあの人の突っ込みが怖いんだわ」って時は事前のレビューもできますのでTwitterなどでご相談ください。 申し込んだけど穴空きそう！助けて！ってときもritouがなんとかしますので安心して参加してみてください。
ソフトウェアエンジニアの彌冨です。 github.com 入社してからもうすぐで2年になろうとしています。 ベンチャーあるあるでいろいろとエンジニア領域外なこともやってきましたが、最近新規サービスをフルスクラッチで作り上げている中で苦労したユーザー認証の話を書きます。 前置き OpenID Connectとは こちらでは実装の話に集中するため、詳細の話は以下のスライドがわかりやすいので参考にしてください（OpenID Connect自体の話はある程度割愛させていただければと思います） OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜 from Masaru Kurahayashi www.slideshare.net ただ、端的に私の理解を述べると、OAuth2.0のプロトコルを拡張してシンプルなアイデンティティレイヤーを足すことで、認証と認可の両方を行うこ
はじめに デジタルトランスフォーメーション(DX)事業本部で新規事業開発をしている八木です。 アウトプットの習慣をつけるために、簡単なところからでもブログ化していこうという思いから書いてみました。 今回はAuth0のデプロイ自動化のお話をさせていただきます。 Auth0のデプロイの自動化をした背景 現在、私のプロジェクトでは認証、認可機能を実装するためにAuth0を採用しているのですが、これまでデプロイまわりで以下の二つの問題を抱えていました。 一つ目は、単純に手間がかかることです。 フロント、バックエンドのデプロイに関してはテスト環境、本番環境のレポジトリにmergeされたら自動でその環境にデプロイされるようになっていました。ただ、Auth0のデプロイに関しては、手動で手元で実行していたため、通常のデプロイフローとは別にデプロイしなければならないという手間がかかっていました。 二つ目は、
『OpenID TechNight vol.22 ~ AI時代のID管理「AIdentity」勉強会』の資料になります。 https://openid.connpass.com/event/356397/
Today, we’d like to highlight a dangerous anti-pattern in the identity world: the false identifier anti-pattern. An anti-pattern is a common response to a recurring problem that’s usually ineffective and risks being highly counter-productive. You may have also heard of the password anti-pattern. Today's discussion represents a possibly even more dangerous practice. The false identifier anti-patte
Twitter OAuth2.0の設定や動作まとめ
はじめに 2021年12月15日にTwitterのOAuth2.0の正式提供開始のアナウンスがありました。 本記事では上記の機能を利用したOAuth2.0 Clientの設定方法や挙動を記録して残します。 なお、Twitterは以下のようなOAuth 2.0 Authorization Code Flow with PKCEと呼ばれるフローを利用しています。 OAuth2.0自体の説明は必要最低限としていますので、詳細については別途以下のOAuth2.0の仕様や記事などを参照いただけますと幸いです。 本記事では説明の都合上、本来十分にランダムな値でなければならないstateやcode_verifier(およびcode_verifierから導出されるcode_challenge)について、固定の値を利用しています。 実際は推測不可能なランダムな文字列を利用するようにしてください。 また、No
Amazon Cognito と AWS Lambda を使って OAuth 2.0 デバイスフローを実装する | Amazon Web Services
Amazon Web Services ブログ Amazon Cognito と AWS Lambda を使って OAuth 2.0 デバイスフローを実装する 本記事は Implement OAuth 2.0 device grant flow by using Amazon Cognito and AWS Lambda | AWS Security Blog を翻訳したものです。 このブログ記事では、Amazon Cognito に OAuth 2.0 デバイス認可フロー (Device Authorization Grant Flow) を AWS Lambda と Amazon DynamoDB を使って実装する方法を学べます。 インターネットに接続されているが、入力機能が制限されていたり、使いやすいブラウザがなかったりするウェラブルデバイス、スマートスピーカ、動画ストリーミングデバ
世界有数のAPI利用企業で考える標準仕様範囲外の仕様とユーザー体験の関係性 - Money Forward Developers Blog
こんにちは、最近ブルグミュラー15曲目（原曲No.20）が終わった内波です。 「じゃあ小学校3年生くらいだね」と言われて少しだけしょんぼりした瞬間もありましたが楽しくやっています。 このブログではだいぶご無沙汰していましたが、最近、我々の会社の立場がかなり稀有なもので、そこで得られている情報をもっと多くの人に広く共有していくべきだな、と感じるようになったので、久々に筆をとりました。 何がそんなに珍しい立場かというと、他社が提供するAPI、その中でも特に、単純な「機能」としてのAPIではない、ユーザーの認可を受けてその代理人として利用するAPIを、これほど多く扱っている企業はなかなかないんじゃないかな、というものです。 はじめに この記事で取り扱うAPI API（アプリケーション・プログラミング・インターフェース）という単語は非常に広い意味で利用されるものですが、この記事でフォーカスするもの
ritouです。 なんか反応いっぱいあったこれですが 一番伝えたかったのは ログインだけなら(ClientSecret)いらねーじゃん なのでその部分を書きます。特に新しい話ではありません。 まとめ まとめます。 OIDCで新規登録やログインさせたいだけ、かつUserInfo API叩かなくていいなら、 client_secretはいらないよ！ Implicitって言っても、OAuth 2.0 の response_type=token は使わん方がいいけど OIDC の response_type=id_token は使っていい みんな大好きSAMLと大体一緒よ。しらんけど。 こんなところですね。 ID連携の時、リソースアクセスしてる？ OIDC Core ってのは IDTokenによる "認証イベント" 情報、ユーザーの属性情報を受け渡し UserInfo APIによる最新のユーザー属
システム関連で幅広い事業を展開しているサイオステクノロジーのプロフェッショナルサービスチームが、日々何を考え、どんな仕事をしているかを共有する「SIOS PS Live配信」。今回は、利用頻度の高いOAuthをテーマにシニアアーキテクトの武井氏が登壇しました。続いて、OAuthの認可の流れと、アクセストークン取得のためのフローについて紹介します。前回はこちらから。 OAuthの認可の流れ武井宜行氏：次に、OAuthの登場人物を説明します。（スライドを指して）いろいろ書いてありますが、OAuthの登場人物をざっくり言うと、認可サーバー、リソースサーバー、クライアント、リソースオーナーです。 さっきの図をベースに説明すると、リソースオーナーはAさんにあたる、Facebookの中の投稿の一覧を保有している人です。認可サーバーは、Aさんを認証する人、認証を提供するサーバーです。リソースサーバーは、
Digital Credentials API のオリジン トライアルのご紹介 | Blog | Chrome for Developers
公開日: 2024 年 9 月 4 日、最終更新日: 2024 年 10 月 16 日 Digital Credentials API のオリジン トライアルは Chrome 128 から開始されます。Digital Credentials API は、ウェブサイトがデジタル ウォレットに保存されている運転免許証や国家 ID などのデジタル認証情報を通じて、ユーザーに関する検証可能な情報を選択的にリクエストできる新しいウェブ プラットフォーム API です。 背景 多くの官公庁や民間企業がデバイスに関連付けられたデジタル認証情報を発行し始めており、現実世界でのデジタル ID が現実のものになりつつあります。たとえば、米国の一部の州（アリゾナ州、カリフォルニア州、コロラド州、ジョージア州、メリーランド州など）では、モバイル デバイスの Google ウォレットなどのデジタル ウォレット アプ
概要 Streamlitは、Pythonで気軽にインタラクティブなウェブアプリケーションを作ることができるパッケージです。私自身も機械学習を使ったデモや可視化ツールとして積極的に活用していますが、そうやってStreamlitアプリを量産して適当にホストしていると、だんだん社内で利用する人が増えてきたり、社外の協力者に使ってもらうことを検討し始めたり……。 そして発生するのがアクセス制限と認証の問題です。特に外部IPで公開する場合は、URLを知っている人なら誰もがアクセスできる状態になってしまい、アプリケーションの内容によってはセキュリティ的に問題となります。私はこれまでStreamlitでid/passの入力ボックスを実装してみたり、GCE上で動いているnginxでBASIC認証を行うなどして制御してきたのですが、やはり個人でアカウント情報を管理するのは面倒かつ不安で、何かしらの基盤上で統
最新の6.0で学ぶ！ 初めてのひとのための Spring Security (株)クレディセゾン 多田真敏 2022年6月28日(2023年1月改訂) JSUG勉強会 1 このセッションについて ▸ Spring Securityの最新情報に基づいて、 基礎から丁寧に解説します ▸ 対象者 ▸ [必須] この資料レベルのSpringのDIコンテナ・Spring MVC ・Spring JDBC・Spring Bootの知識がある方 ▸ Spring Securityを使うのが初めての方 or Spring Securityを使ったことはあるけど知識をアップデートしたい方 ▸ 以下はスコープ外とします ▸ OAuth、OpenID Connect、SAML、Kotlin、WebFlux 2 https://www.docswell.com/s/MasatoshiTada/5Q4EMZ-spr
SPAにおける理想的な認可 - Qiita
こんにちは、kura（倉林 雅）です。 この記事はDigital Identity技術勉強会 #iddance Advent Calendar 2022の23日目の記事です。 前回、Cookie・OAuth 2.0・OpenID Connectの目的別プロトコル選定において目的別での適切なプロトコルのお話をいたしました。 今回はその話に関連したSPAにおける認可についてご紹介します。 なぜSaaSにおけるSPAではOpenID ConnectとID Tokenを用いるのか？ はじめに、プロトコル選定や設計・実装において多くの開発者の誤解に繋がっているのではないかと思われる仕様について触れたいと思います。 前回のお話では、新規にSPAを提供する場合はOAuth 2.0を選択するで解説したようにSPAでアプリケーションを提供する際には、OAuth 2.0による認可を行いフロントエンドのJava
Configuring OpenID Connect in Amazon Web Services - GitHub Docs
Overview OpenID Connect (OIDC) allows your GitHub Actions workflows to access resources in Amazon Web Services (AWS), without needing to store the AWS credentials as long-lived GitHub secrets. This guide explains how to configure AWS to trust GitHub's OIDC as a federated identity, and includes a workflow example for the aws-actions/configure-aws-credentials that uses tokens to authenticate to AWS
2023年3月6日紙版発売 2023年3月6日電子版発売 大竹章裕，瀬戸口聡，庄司勝哉，光成滋生，谷口元紀，くつなりょうすけ，栃沢直樹，渥美淳一，宮川晃一，富士榮尚寛，川﨑貴彦 著 B5判／160ページ 定価2,178円（本体1,980円＋税10%） ISBN 978-4-297-13354-2 Gihyo Direct Amazon 楽天ブックス 丸善ジュンク堂書店 ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 本書は，Webシステムのセキュリティを支える技術を幅広く解説します。具体的には，公開鍵暗号，共通鍵暗号，ディジタル証明書，電子署名，認証・認可などの基礎技術の用語や理論の説明から，それらを応用したSSL/T
ritouです。 某イベントのこの辺で出てくる質問に回答してみました。 Q. SAMLとの違い A. OAuthとは目的/用途が異なる。OIDCとの比較では、SAMLをモダンにしたのがOIDCという認識でおk。XML->JSON, XML Signature->JWTみたいな仕様の違いがある。あとはOIDCはSPAやモバイルアプリ、Verifiable Credentialsといった世の中の動向に追従して現在進行形で拡張仕様やプロファイル、ベストプラクティスの策定が進められている。 Q. 言葉の定義 A. 英語では決まっている。日本語に変換するときにおかしくなったり、IDaaSなどでOIDCをそのまま適用していない場合などで用語の混乱が起こりうる。 Q. 人間が介在しない認証フローではImplicit?非推奨？ A. おそらくClientCredentialsの方が適している Q. Con
自己主権型IDと分散型ID
自己主権型アイデンティティと分散型ID（Identifier）、分散台帳の使い方についてRead less
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに OAuth2.0の拡張仕様で当たり前になりつつある？PKCEについてまとめました。 「PKCE」とは PKCEとは、「Proof Key for Code Exchange by OAuth Public Clients」の略称で、認可コード横取り攻撃を対策するための、OAuth2.0の拡張仕様です。 みんな大好き？RFCの7636に定義されています。 RFCに読み方も定義されており、「PKCE」も定義されています。 PKCE, pronounced "pixy" とあるので「PKCE」は「ピクシー」と読みます。 ※ ポケ○ン
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linux Foundation、OpenID Connectを拡張した暗号化プロトコル「OpenPubkey」をローンチ | gihyo.jp
OAuth/OIDCをまとめてみる(下書き段階です！)
「GitHub Actions × AWS」のトレーサビリティ向上委員会
リダイレクト URI の前方一致 - Qiita
JWM: a new standard for secure messaging
とほほのOpenID Connect入門 - とほほのWWW入門
標準化でどう変わる!? 話題の次世代分散ID規格「DIDs」のポテンシャルをえーじさんに聞いてみた!
OAuthのメリットは認可のためのプロトコルであること 従来のID・パスワードを利用した場合と比較した、OAuthの特徴とフロー | ログミーBusiness
⺠間事業者向け デジタル本⼈確認ガイドライン 第1.0版
セキュアなトークン管理方法 - Carpe Diem
OpenID Connect についてと OAuth2.0 との違いを調べてみた
OpenIDConnect+Deviseでの認証クライアントの実装 - ANDPAD Tech Blog
Auth0のデプロイをGitHub Actionsで自動化した話 - Speee DEVELOPER BLOG
OAuth/OpenID Connectで実現するMCPのセキュアなアクセス管理
The False Identifier Anti-pattern
「Thunderbird 91.8.0」が公開、「Gmail」でOAuth 2.0への自動移行を実施【4月7日追記】／9件の脆弱性も修正
OIDCのImplicit FlowでClientSecretを使わずにID連携する
OAuthの認可はどのような流れで進むのか？ アクセストークン取得のための3つのフロー | ログミーBusiness
StreamlitでGoogle OAuth2.0を使った認証を行う
最新の6.0で学ぶ！初めてのひとのためのSpring Security | ドクセル
今さら聞けない暗号技術＆認証・認可 ―Web系エンジニア必須のセキュリティ基礎力をUP
"仕様が読めるようになるOAuthとOpenID Connect入門"の質問への回答
OAuth2.0 PKCEとは 〜Stateとの違い〜 - Qiita
indeep.jp
podcasts.apple.com
sagasitasekai.com
genomicsworkshop.isr.umich.edu
digital.asahi.com
genomicsworkshop.isr.umich.edu