社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意く…
30分でOpenID Connect完全に理解したと言えるようになる勉強会
社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意く…
OAuth 2.0 クライアント認証 - Qiita
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
実装者による Financial-grade API (FAPI) 解説 - Qiita
注記: 2021 年 3 月に公開された FAPI 1.0 最終版に対応するため、本記事の内容を大幅に更新しました。タイトルも『世界最先端の API セキュリティー技術、実装者による『FAPI（Financial-grade API）』解説』から『実装者による Financial-grade API (FAPI) 解説』に変更しました。本記事の英語版は "Financial-grade API (FAPI), explained by an implementer" です。 はじめに Financial-grade API（通称 FAPI; ファピ）は、OpenID Foundation の Financial-grade API ワーキンググループが策定した技術仕様です。OAuth 2.0 と OpenID Connect（以降 OIDC）を基盤とし、より高い API セキュリティーを必
Financial APIs Workshop 2018
～ Japan/UK Open Banking and APIs Summit 2018 ～ API 提供・利用に携わる開発者向けに OAuth 2.0 / OpenID Connect / FAPI を中心とする『金融 API 』の最前線をご紹介 欧州での PSD2 を筆頭に、世界各国金融機関でのAPI公開が進んでいます。その中でも英国では国策として “Open Banking” を謳い、銀行に対する義務化や技術標準の整備を完了しています。 一方、国内では改正銀行法をうけて銀行業界での API 公開が進展し、その流れがクレジットカード・証券・保険などにおいても波及しつつあります。しかしながら、技術仕様の標準化やエコシステム醸成の点からは、いまだ不十分と言えます。 本イベントは、英国 Open Banking を中心とする国内外の最新動向を、ビジネスとテクノロジーの観点から参加者と共有し、
金融 API 時代のセキュリティ: �OpenID Financial API (FAPI) WG
タイトル： 『認証の課題とID連携の実装 �〜ハンズオン〜』 概要： FIDO、ID連携（OAuth・OpenID Connect）をはじめとした最近の技術をご紹介します。FIDOは端末とサーバー間でユーザー認証を安全に連携するための仕組みです。OpenID Connectはユーザーの認証と認可を連携するためのID連携の仕組みで、OAuth 2.0を拡張した仕様であり、HTTP通信やJSONなど基礎的なWeb技術によって構成されています。FIDOとID連携の技術を学んだ後、実習ではGolangを用いてWebアプリケーション上にOpenID Connectを実装します。実装の注意点とそのリスク、仕様に施されているセキュリティー対策についてハンズオンを行いながら解説します。 セキュリティ・キャンプ全国大会2019 専門講義 選択コース B4 認証の課題とID連携の実装 〜ハンズオン〜 Aug
OAuth 2.0の代表的な利用パターンを仕様から理解しよう
連載 INDEX 次回 → はじめまして、OpenID Foundation Japan事務局長のNovです。 このたびは、Build InsiderでOAuth 2.0とOpenID Connectに関する記事を書かせていただくことになりました。 今回はOAuth 2.0、次回はOpenID Connectについて、ユースケースごとのフロー（Flow）や関連仕様についてまとめていきます。 OAuth 2.0仕様策定から5年 OAuth 2.0はIETF OAuth WG*1で仕様策定されている標準仕様群である。 最もコアとなるRFC 6749＆RFC 6750はどちらも2012年にRFC化されており、すでに策定から5年以上が経過している。OpenID Foundation Japanの翻訳WGでもこれらは翻訳済みである。 The OAuth 2.0 Authorization Frame
オッス！オラ認証周りをまとめてみた - どんまいこのネタ帳
こんにちは。今日は趣向を変えて千代田区立図書館に来てみました。 www.library.chiyoda.tokyo.jp 図書館は普段あんまり行かないので、地元の図書館との違いに驚きでした。 都内の図書館って広いし綺麗ですね。 九段下から割と近い、置いている蔵書のジャンルが多し、席のジャンル多し、無線Wifiあり、電源あり、でかなり使いやすかったです。 静かで落ち着いた雰囲気で過ごしやすい気がしますが、無音なので独り言が多い人は気をつけてください。 さて、前回の記事について@okeee0315さんからこんなコメントを。 認証回りは大事、ADの前に認証と認可が必要かも / ADなにそれおいしくない(泣) - どんまいこのネタ帳 https://t.co/MEFI6o5qNA— okeee (@okeee0315) 2016年5月3日 ほほう。ADはまだ美味しくなかったので、教えに従い認証周り
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
はじめに この文書では、OAuth 2.0 + OpenID Connect サーバーをゼロから一人で実装した開発者（私）が、得られた知見について書いていきます。基本的には「実装時に考慮すべき点」を延々と述べることになります。 そのため、この文書は、「素早く OAuth 2.0 + OpenID Connect サーバーを立てる方法」を探している方が読む類のものではありません。そのような情報をお求めの方は、「Authlete を使って超高速で OAuth 2.0 & Web API サーバーを立てる」を参照してください。そちらには、「何もない状態から認可サーバーとリソースサーバーを立て、アクセストークンの発行を受けて Web API をたたいて結果を得る」という作業を、所要時間 5 ～ 10 分でおこなう方法が紹介されています。 文書のバイアスについて 私は、OAuth 2.0 + Ope
Automation Accountパターン - 世界線航跡蔵
コンテキスト あなたが開発しているサービスはユーザー向けにAPIを提供している。そして、APIを利用するにはユーザーは短寿命の認可情報(たとえばOAuth2トークン)を提示しなければならない。 ユーザーは認可情報が紐付いているアカウントの権限でリソースを読み取ったり、作成したり、所有したり、編集または削除したりする。 ここで、ユーザーは人間(が操作するユーザーエージェント)であることもあるが、人間の手を離れてバックグラウンドで自動実行されるプログラムかもしれない。 また、あなたは悪用目的でアカウントが大量登録されるのを防ぐためにCaptchaを利用したいと思っている。 さらに、課金目的で請求書送付先を登録させたいとも思っているかもしれない。 問題 プログラムが利用するアカウントを安全に管理するのがユーザーにとって困難である。 プログラムは自分でCaptchaを解いたりEメールを受け取るのが
モバイルアプリのユーザ認証方法についてまとめてみた - Qiita
追記 (2018-10-08) 4年以上前に書いた記事ですが、Access Token として JWT を利用することは非推奨なようなので、お詫びして修正致します。 参考: どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ 概要 みんなやってるはずなんだけど、あまりまとまった情報がなかったので書いてみます。認証周りはセキュリティを気にして、みんな書きたがらないのかな？それとも私の調べ方が悪かっただけ？マサカリお待ちしてます。 認証の基本方針 +--------+ +--------+ | | | | | |----(1) Credential ------------>| | | | | | | |<---(2) Access Token -----------| | | | | | | Client | | Server | | | | | | |----(3)
Basic認証とOAuth - Qiita
Basic認証とOAuthとその辺の情報について整理しておく。OAuthや認証・認可について説明しようとすると、1文字記述するたびに誤りが含まれてしまう可能性があるので、本当に緊張感を持って記述しなければならない。それでもなお、この文章にはたくさんの誤りが含まれている。 UsernameとPasswordを受け取って認証する形式の認証方法。UsernameにはEmailを使うこともある (要は全ユーザの中で一意なことが保証されていてかつ他の人がその値を知っていても特に問題がないという情報であればOK)。Passwordは本人しか知り得ない情報。 OAuthという仕様に則って提供される認可方法。古いOAuth 1.0と、OAuth 1.0の複雑なところなどを改善したOAuth 2.0がある。一般的にはOAuth 2.0を使うことが多いが、例えば幾つかのサービスの提供している認可方法はOAut
クックパッドとマイクロサービス - クックパッド開発者ブログ
技術部の高井です。 最近、日本でもマイクロサービスという言葉が流行しつつあります。 今回は、なぜクックパッドがマイクロサービスを選択したのか、また実際にどのようなやり方をしているのかということを紹介します。 Conwayの法則 ここ数年の間、クックパッドはレシピの投稿・検索サービスから「食を中心とした生活のインフラ」として事業領域を拡大しつつあります。海外レシピサービスの買収による海外展開は、単なる金銭的な関係にとどまらず、人的・技術的な交流も含めて本格化しつつあります。また、「モバイルファースト」を標語とするモバイルアプリケーションへの取り組みも加速してきました。 事業領域の拡大やグローバル展開、モバイルファーストといったビジネス要求の変化に応じて、会社の組織構造も変化しています。そして、Conwayの法則 として知られているように、組織構造とソフトウェアアーキテクチャには密接な関係があ
RFC 6819: OAuth 2.0 Threat Model and Security Considerations
Internet Engineering Task Force (IETF) T. Lodderstedt, Ed. Request for Comments: 6819 Deutsche Telekom AG Category: Informational M. McGloin ISSN: 2070-1721 IBM P. Hunt Oracle Corporation January 2013 OAuth 2.0 Threat Model and Security Considerations Abstract This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive thr
Implicit Flow では Covert Redirect で Token 漏れるね - OAuth.jp
この記事は、先ほど書いたこちらの記事の訂正版です。 記事に入る前に、まずは全シンガポールにお詫び申し上げますm m さて、Covert Redirect についての説明は…超絶取り消し線はいりまくってる前の記事を読んでください、でいいでしょうか？ で、訂正分だけ以下に。 Fragment Handling in Redirect 宮川さんが記事にしてますね。 英語だけど。 で、まぁ要するに、(Modern Browser は) 30x リダイレクト時にリダイレクト元に付いてた URL fragment をリダイレクト先にも引っ付ける、と。 fragment は server-side には送られないけど、クライアントサイドではリダイレクト先に引き継がれる、と。 試しに http://www.idcon.org/#foobar にアクセスすると、http://idcon.org/#fooba
OpenID Foundation Japan
公開資料 OpenIDファウンデーション・ジャパンでは、OpenID関連技術仕様の日本語訳や、プレゼンテーション資料、その他各種文書を公開しています。 技術仕様 OpenID Connect OpenID Connectは、OAuth 2.0をベースとする、シンプルなアイデンティティ連携プロトコルです。 ここでは日本語訳された仕様を紹介しています。原文ならびにその他の仕様については http://openid.net/connect/ をご参照ください。 OpenID Connect 1.0 specification OpenID Connect Core 1.0 日本語訳 OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server
Final: OAuth 2.0 Form Post Response Mode
Abstract This specification defines the Form Post Response Mode. In this mode, Authorization Response parameters are encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client, with the result parameters being encoded in the body using the application/x-www-form-urlencoded format. Table of Contents 1. Introduction 1.1. Req
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アプリ開発で知っておきたい認証技術 - OAuth 1.0 + OAuth 2.0 + OpenID Connect -
これからの Microservices
http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
DeNA Engineering - DeNAエンジニアのポータルサイト