Basic認証、Digest認証、Bearer認証、OAuth認証方式について - プログラミング初心者がアーキテクトっぽく語る
Basic認証、Digest認証、Bearer認証、OAuth認証方式はRFCで標準化されている認証方式の中で最もよく目にする方式だろう。 Basic認証とDigest認証は多くのサーバ、クライントで実装されており導入障壁が低い認証方式だ。 機密性の高いデータを扱うサービスでは比較的安全なBearer認証、OAuth認証方式を目にすることが多い。 ここではBasic認証、Digest認証、Bearer認証、OAuth認証方式について簡単に触れる。 この4つの概要を理解しておけば大体のWebサービスは理解できるだろう。 もしサービスが固有の認証方式を実装していた場合でもこれらの方式との類似性に着目すればすぐに理解できるはずだ。SAMLやOpenIDと言ったより複雑な認証方式を理解する上でも助けになると考える。 1. Basic認証方式 最も理解しやすいのがBasic認証方式だ。RFC 261
OAuth 2.0 が解決するAPI連携の課題 - LayerX エンジニアブログ
こんにちは！バクラク事業部の@ysakura_です。普段はバクラクビジネスカードの開発をしています。 先日、Partner APIの開発を担当する事になり、その前段としてバクラクシリーズ全体で利用できる OAuth 2.0 の認可サーバーを開発しました。 OAuth 2.0 により、Partner APIのセキュリティ向上を目的としています。 今回は入門記事として、 OAuth 2.0 の元となる課題感 / OAuth 2.0 での解決方法 / API Key方式との比較 を画像を交えながら説明します。OAuth 2.0 は分かった様で分からない状態になる事も多いと思うので、理解の一助になれば幸いです。 ※ あくまで入門記事ですので、OAuth 2.0 の詳細なフロー図などは出てきません。 前提となるシナリオ 他社のシステム(SaaS等)にデータを連携するシーンを考えます。 例として、バク
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については別ブログにすると言っていたのですがサボり続けた結果、全て忘れ去り再び調べる羽目になりました。これはまた
OAuth 2.0 for Browser-Based Apps
OAuth 2.0 for Browser-Based Apps Abstract This specification details the security considerations and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0.¶ Discussion Venues This note is to be removed before publishing as an RFC.¶ Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.
RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens Abstract This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either
OAuthの言葉周りを整理する
OAuthの仕組みとToken認証周りの言葉はいつまで経ってもはっきり理解できないものの一つでした。 しかし最近ようやく理解できるようになってきたのでとりあえずそれぞれの言葉の指すものや定義をここで整理してみようと思います。 リフレッシュトークン リフレッシュトークンとは アクセストークンの有効期限が切れたときに、認可サーバーにアクセストークンの更新リクエスト認証をするためのトークン。 OAuth自体はリフレッシュトークンがなくとも実装できるが、リフレッシュトークンはOAuthをより便利にするためのもの。 一般的に有効期限は長い。 ないとどうなるのか アクセストークンの期限が切れたらその度にSNS認証のあのログイン画面に飛ばされてメアドとパスワードの入力が必要になる。 セキュリティに関すること 有効期限が長くても安全性に問題がないと考えられる理由としては、アクセストークンの期限切れ時にしか
OAuth 2.1 のドラフトから OAuth 2.0 のプラクティスを学ぶ - VA Linux エンジニアブログ
はじめに OAuth 2.0 と OAuth 2.1 の違い 1. Authorization Code grant フローでは PKCE を標準で使用する 2. リダイレクトURIの検証は文字列の完全一致で行わなければならない 3. Implicit grant フローは仕様から除去される 4. Resource Owner Password Credentials grant フローは仕様から除去される 5. Bearer トークンをURIのクエリ文字列として渡す方法は仕様から除去される 6. パブリッククライアントでは、リフレッシュトークンを利用できる送信者または利用回数を制限する 何をしないといけないか 執筆者 : 山下雅喜 はじめに OAuth 2.0 が RFC 6749 (The OAuth 2.0 Authorization Framework) としてリリースされてから1
雰囲気でOAuthを使っていたエンジニアがOAuthサーバ(RFC6749)を自作してみる
はじめに Auth屋さんの本やその他有識者のBlogなどを読むことで少しながらOAuthやOIDCの仕組みが理解できてきました。 そんななかで以下の記事が大変勉強になりました。 ↑の記事ではRubyで実装されているのですが、これを参考というかほぼ丸コピですがgolangで実装してみたいと思います。 コードは以下にあります。 仕様 OAuthサーバでは認可エンドポイントとトークンエンドポイントを実装する必要があります。 認可とトークンエンドポイントの2つに加えてユーザ認証を行うエンドポイントを作ります。 今回は元記事と同じようにFormに入力したユーザ&パスワードを受け取り確認します。 RFC6749に関する仕様は元記事の2.注意点と同じになるはずです。 「はずです」というのは恥ずかしながらまだ完全な理解に至っておらず今もRFCを読みながら答え合わせ中です。 ぜひ認識違いがあればご指摘くださ
FAPIとKeycloakの概要
連載の1回目である今回は、FAPIの概要並びに、IAMのKeycloakのFAPI対応について紹介します。 はじめに サービスデリバリのアジリティを高めるために、今やサービス開発にAPIを利用することは必要不可欠となっています。また既存サービスに新たな価値を付与するために、APIを公開することも常套手段の一つとなっています。このようにAPIに触れる機会が日常にあふれている一方、APIに対して適切なセキュリティ設計を行わなかったために、機密性の高い情報が漏えいしてしまったり、金融取引に関わる不正操作を許してしまったりという事故や事件は後を絶ちません。攻撃者による攻撃が日々進化をし続けている中、APIを公開するシステムに求められるセキュリティ要件は日々高度化しています。 そんな中で注目を集めているのが、Financial-grade API Security Profile（以下、FAPI）で
全員がOAuth 2.0を理解しているチームの作り方 #devio2021 | DevelopersIO
DevelopersIO 2021 Decadeで「全員がOAuth 2.0を理解しているチームの作り方」というテーマで話させていただきました。 DevelopersIO 2021 Decade で「全員がOAuth 2.0を理解しているチームの作り方」というテーマで話させていただきました。 スライド 話した内容 なぜ人類は OAuth 2.0 に入門し続けるのか なぜ OAuth 2.0 をチームに根付かせたいのか 開発フローとしてコードレビューがある 仕様がわからないと、レビューができない コードと仕様のすり合わせのために仕様が分かる必要がある OAuth 2.0 はまあまあややこしい OAuth 2.0 では登場人物が4人いて、それぞれがいろんなやりとりをします。 それぞれのやりとりにパラメーターがあるので、誰が誰にどういう値をどうして送る、みたいなところまで考えるとまあまあやや
API Tokens: A Tedious Survey
API Tokens: A Tedious Survey Author Name Thomas Ptacek @tqbf @tqbf Image by Annie Ruygt We’re Fly.io. This post isn’t about Fly.io, but you have to hear about us anyways, because my blog, my rules. Our users ship us Docker containers and we transmute them into Firecracker microvms, which we host on our own hardware around the world. With a working Dockerfile, getting up and running will take you l
OAuth2の次に来ると言われる認可プロトコルGNAPとはなにか | メルカリエンジニアリング
Merpay Advant Calendar 2020、23日目の記事は、趣味で認証認可をやっている @nerocrux が送りいたします。 最近 GNAP という認可プロトコルのワーキンググループドラフトが出ていて頑張って細かく読みましたので、（次回はいい加減に仕事でやってることについてお話しますが）今回はその GNAP について紹介させてください。 GNAP とはなにか？ GNAP は Grant Negotiation and Authorization Protocol の略で、認可のプロトコルです。Justin Richerさんという方を中心に策定しています。作者によると、GNAP の発音は げなっぷ になります。 認可（Authorization）プロトコルと言えば、OAuth 2.0 (RFC6749) が広く知られ、運用されています。GNAP は OAuth 2 の後継とし
KeycloakによるAPIセキュリティの基本
連載の1回目である今回は、Keyclooakの基本および、API保護が必要とされる背景について解説します。 サービスがより活発に利用されることを狙って、企業や公的機関によるサービスのAPI（Application Programming Interface）公開が広がっています。また、自組織内でもモバイルアプリケーション開発やシステム間連携を行いやすくするために、システムがAPIを提供することが多くなってきています。その際、APIは限られた人やシステムにだけがアクセス可能にする必要があるため、認証・認可のようなセキュリティ技術が必須になってきます。 認証・認可は、OAuth 2.0の枠組みに基づくことが一般的ですが、OAuthは自由度が高い仕様であるため、誤って実装・構築してしまうとセキュリティホールが作りこまれてしまいます。本記事では、近年急成長を遂げている認証・認可サーバOSSである「
JWT+RDBを用いたOAuth 2.0 ハイブリッド型トークンの実装例 - r-weblife
おはようございます、ritouです。 (⚠️認可イベントの識別子のあたり、ちょっと見直しました！最初に見ていただいた方はもう一回どうぞ！) 前回、ハイブリッド型と呼ばれる OAuth 2.0 のトークン実装について書きました。 ritou.hatenablog.com その続きとして JWT(JWS) + RDBでできる実装例を紹介します。 理解するにはそれなりの OAuth 2.0 に関する知識が必要になるかもしれませんが、よかったら参考にしてみてください。 何を考えたのか OAuth 2.0のRefresh Token, Access Tokenを考えます。 要件から整理しましょう。 要件 結構ありますが、最低限の OAuth 2.0 の Authorization Server を実装しようと思ったらこれぐらいはやらないといけないでしょう。 RFC6750 で定義されている Bear
OAuth 2.0/OIDCに入門した開発者が仕様沼に潜るための次のステップとは？ - r-weblife
お疲れ様です、ritou です。 OAuth 2.0やOIDCの入門書(?)を読み終えた開発者の方に、仕様を理解していくための次のステップは何があるかを聞かれました。 そもそもそんなこと言う人は クライアントを実装したい(しなければならない) 認可サーバーを実装したい(しなければならない) セキュリティエンジニアを名乗っていてこの分野を抑えときたい ただ単純に興味がある : そんな人いる？ とかそんな感じな気はしますが、基本的なフローを乗り越えた先に広がる仕様沼への潜り方に戸惑っておられるようでした。 そこで、いわゆる RFC6749/6750/7636 あたりを完全に理解した開発者が山ほどある仕様にどう立ち向かっていくかを考えます。 仕様にも色々ある IETF の OAuth関連の仕様、いっぱいあります。密です。密です。みみみみみみみみ... tools.ietf.org 去年に一回まと
SSHログイン時に公開鍵認証とGoogle OAuthで多要素認証する | ten-snapon.com
# ブラウザで認証後表示されたコードをペーストする Please type code:xxxxxxxxxxxxxxx sshでサーバにログインする際に、まず公開鍵認証が行われ、正解するとたーみなるに、このURLを開いてくれというメッセージが出ます。 https://accounts.google.com/o/oauth2/auth?access_type=offline&client_id=xxxxxxxx-xxxxxxxxxxx.apps.googleusercontent.com&redirect_uri=uxxxxx 上記の部分ですね。これをブラウザに貼り付けて、Googleの認証を超えると、あるコードが払い出されるので、それをターミナルに貼り付けると無事ログインできます。また、ログイン後はトークンが有効期限のうちは再度oAuthする必要はありません。 インストール方法 OAuth
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Nango - The fastest way to ship integrations
世界一わかりみの深いOAuth入門
認証と認可の超サマリ OAuth とか OpenID Connect とか SAML とかをまとめてざっと把握する本
2020年のSlack App開発者が知るべき最新のSlack API仕様 | PLAID engineer blog
