サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
「SRE ×技術負債解消」のぶっちゃけ話LT会 https://coconala.connpass.com/event/314300/ で発表したスライドです
すべての経済活動を、デジタル化するために、すべての業務活動を、デジタル化したいコーポレートエンジニアリング室の @yuya-takeyama です。 7月はBetTechnology Monthということでブログがたくさん出てくる月です。 そして7月といえば、第二四半期の始まりですね。 今月から転職や異動によって新しい環境で働き始める方も多いのではないでしょうか。 LayerXでは毎月のように入社・異動があるため、その度にやらないといけないことがあります。 それは、各種グループのメンバーの更新です。 LayerXにおけるグループメンバーの管理 LayerXではID基盤としてMicrosoft Entra IDを利用しています。 また、SCIMプロトコルを利用した自動プロビジョニングにより、そこから各種SaaS (Google Workspace,Slack,Notion,AWS,
みなさんこんにちは、バクラク事業部 Platform部 IDチームの @convto です。 最近MCP関連の仕様や議論をウォッチしており、今回はエンタープライズ向けの MCP 認可に関する提案内容などについて紹介したいと思います！ 現行の認可仕様 2025-06-18 版の仕様は以下です。 ここには HTTP ベースの認可は OAuth 2.1 準拠でやるよ！ということが書かれています。 大まかな内容としては以下のようになっています。 MCPサーバーは OAuth 2.1 リソースサーバーとして振る舞う [SHOULD] 認可サーバーは Dynamic Client Registration (RFC7591) をサポートする OAuth client を動的に登録できる仕様 定義を読むと利便性を意識しての推奨サポートのよう DCR をサポートしない場合 client_id などを何らか
https://aiau.connpass.com/event/365588/
はじめに こんにちは、GMO FlattSecurity株式会社セキュリティエンジニアの小武です。 先日公開した記事「Passkey認証の実装ミスに起因する脆弱性・セキュリティリスク」では、「8. Non DiscoverableCredentialのフローとの混在」において、StrongKey FIDO Serverのアカウント乗っ取りが可能な脆弱性について言及しました。StrongKey FIDO Serverはオープンソースで提供されているFIDOサーバー製品です。 この脆弱性は、様々なセキュリティ的利点を持つPasskey認証であっても、実装ミスによって脆弱になり得るということを示しています。本記事では、この脆弱性がソースコードレベルでどのような問題を含み、どのように修正されたのかを詳しく解説します。 また、GMO FlattSecurityはPasskey認証に特化した脆
はじめに こんにちは、GMO FlattSecurity株式会社セキュリティエンジニアの小武です。 近年、WebAuthn、特にPasskeyはパスワードレス認証への関心の高まりや利便性の高さから、普及が進んでいます。 WebAuthnによるPasskey認証は強固な認証手段ですが、複雑な認証基盤の実装に不備があると、依然としてアカウント乗っ取りを含む従来のセキュリティリスクを払拭できません。本記事では、W3CのWorking Draft(2025年5月現在)である Web Authentication: AnAPI for accessing Public KeyCredentials Level 3 を読み解き、Relying Party(RP)としてPasskey認証を導入する際に実装で注意すべき点を説明いたします。 はじめに Passkey認証でも生まれ得るセキュリティリ
ritouです。今日はこの話です。 SSO=一度ログインしたら複数RPに一括でログイン可能みたいなイメージに対して、OIDCでの動きは個々のRPがそれぞれ自分達向けのIDTokenを受け取りそれを信用してログイン状態にするだけ。 https://t.co/R4qNOrcY8h— 👹秋田の猫🐱 (@ritou) 2025年5月9日 ここで扱うSSO（シングルサインオン）とは、一般的に「一度の認証処理で、複数の独立したシステムやサービスへアクセス可能になる仕組み」を指します。本稿では、このSSOをID連携の主要な実現手段の一つであるOIDC (OpenID Connect) がどのように実現するのかについて解説します。 ID連携を用いないSSOの実現方法：単一セキュリティドメイン内でのアプローチ まずID連携について触れる前に、単一のセキュリティドメイン（ID管理が一元的に行われる範囲）
PS部兼AT部の廣田です。 貴方がこの記事を読んでいる頃には、私はもう会社に居ないでしょう。（育休的な意味で） 最近、AWS Cognitoを使ってID管理を行っているシステムをよくみかけるようになりました。Cognitoは、面倒なログイン周りのアレコレを一手に引き受けてくれる便利なAWSのマネージドサービスです。パスワードの取り扱い、emailの到達確認、SMS、パスワードリセット、MFAデバイスの管理などなど……。これらをAWSがマネジメントしてくれるとなれば、独自実装するよりもそちらを使いたくなる人は多いのではないでしょうか。 ただ、実装を行わなくて良いかわりに、安全に利用するためには色々な設定が必要となります。もっともシンプルな Webアプリケーションでは自由にユーザ登録可能 Webアプリケーション側ではユーザの識別のためにJWTのsubクレーム（以降subと表記）のみを利用 とい
認可コードグラント RFC 6749で定義されるOAuthの認可コードグラントでは、認可サーバの実装として、認可エンドポイントとトークンエンドポイントの2つが必要です。リクエストは大きく分けて認可リクエスト (Authorization Request) およびトークンリクエスト (Access Token Request) の2つに分けられます。 全体のシーケンス図は以下の通りです。 PlantUMLのソースコード @startuml @startuml title 認可コードグラントにおけるシーケンス図 autonumber actor RO as "リソースオーナー" participant UA as "User-Agent" participant C as "クライアント" participant AS as "認可サーバ" participant RS as "リソースサーバ
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」は「ピクシー」と読みます。 ※ ポケ○ン
はじめに 私は、手を動かしながらOAuth2/OIDC認可コードフローを学びたいと思い、この記事を書きました。本記事ではAmazon Cognitoを使ってOAuth2/OIDCの認可フローを学ぶハンズオンです。使用するのはCurlだけで、アプリケーションコードの準備は不要です。 目次 登場人物は4人 認可コードフローの概要 詳細な手順セキュリティを向上させるために まとめ 登場人物は4人 1. クライアント(フロントエンド) Webアプリや、モバイルアプリなど、ユーザーの目に触れる画面を指します。今回は画面がないので、curlコマンドなどで代用します。 2. 認可エンドポイント(API) ユーザーの入力したIDやPasswordを検証し、認証が成功した場合に認可コードを発行します。この時点ではログインに成功していません。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? JWTとは JSON Web Tokenの略。ジョットと読むらしい。 ざっくりいうとJsonに電子署名を加え、URL-Safeな文字列にしたTokenのこと 正確にいうと、電子署名を使用する方式はJWS（JSON Web Signature）と呼ばれ、別途暗号化を使用するJWE（JSON Web Encryption）も存在する。よく見かける説明はJWS方式のほう。 JWS方式の場合、電子署名であり暗号化ではないため、中身を見ることは可能。但し改ざんはできない、という仕組み。 実際のユースケースで言うと、サーバ側で認証情報が入ったJso
パスキーの本質はユーザー側としてはパスワード入力機会の削減、サービス側としては企業のセキュリティリスクのユーザーへの責任転嫁とコストカットである。 サービス側 企業がユーザーにパスキーを使わせようと強要するのはログイン情報の流出や流出したログイン情報による攻撃のリスクと責任とコストから企業を守るために認証に関する問題がユーザーの責任によってしか発生しないよう責任転嫁したいからに過ぎない。このため認証情報の紛失や盗難などによる喪失リスクと復旧の困難性やその他新たに発生する問題については隠蔽または矮小化される。企業にとってパスキーとはパスワードの定期的変更の最新版なのでありユーザーがパスキーを強要されるのはパスワードの定期的変更を強要された歴史を繰り返しているに過ぎない。 ユーザー側 パスキーの適切な実装におけるユーザーの本質的利益はパスワード入力機会が減ることによりフィッシング被害を受ける機
以下の講演資料です。 https://axies.secretari.jp/conf2024/program/organizations#_11AM2A
こんにちは。 この記事はfreee Developers Advent Calendar 2024 - Adventar 12/09(9日目)の記事です。 adventar.org 今日は「共通管理基盤開発チーム」の "にいおか" が担当します。 昨日は shikakun さんのfreeeで1年間働いてわかった「ふつう」のアクセシビリティ -freee Developers Hub でした。shikakun さんが入社して1年弱の間に実感したfreee のアクセシビリティへの取り組みについて書かれています。私も入社してそれなりの年月が経ちますが、アクセシビリティへの向き合い方・重要視する姿勢は一貫して変わっていないなと感じます。これはfreee の凄さであり強みであるなと改めて実感した記事でした！本記事では「共通管理基盤サービス」に SAML 認証の仕組みを作成し、既存の「管理
はじめにWikipedia の JWT (JSON Web Token) に関する記事が誤っていたので、2020 年 5 月 9 日、英語版、日本語版ともに修正を行いました。 修正前の記事では、JWT のことを「JSON をベースとしたアクセストークンのためのオープン標準である」と説明していました。しかし JWT は用途を限定しない汎用的なデータフォーマットです。アクセストークンのフォーマットとして JWT を採用することは、JWT の応用事例の一つに過ぎません。なお、アクセストークンのフォーマットは必ずしも JWT とは限りません。→ 参考:『図解 JWS/JWE/JWT/IDトークン/アクセストークンの包含関係』 JWT を知らない状態で OAuth と OpenID Connect の学習を始めると、「JWT はアクセストークンのための技術である」、「JWT はユーザ認証のための技
これは、豆蔵デベロッパーサイトアドベントカレンダー2022第8日目の記事です。 JSON Web Token(JWT)の単語を目にすることがよくあると思いますが、それと一緒に認証と認可や、RSAの署名や暗号化、そしてOpenIDConnectやOAuth2.0までと難しそうな用語とセットで説明されることも多いため、JWTって難しいなぁと思われがちです。しかし、JWT自体はシンプルで分かりやすいものです。そこで今回は素のJWTの説明からJWS、そしてJWT(JWS)を使った認証を段階的に説明していきます。 おな、この記事はJWT全体の仕組みや使い方の理解を目的としているため、以下の説明は行いません。 RSAやHMACなど暗号化やアルゴリズムの細かい説明 JWTを暗号化するJWEとJSONの暗号鍵表現のJWKについて OpenIDConnectとOAuth2.0について 記事は上記のような内容
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
