GCP と OAuth2
はじめにGCP のサービスにプログラムからアクセスするためには必ず認証・認可が必要ですが、以下のような様々なコマンドや概念が出てくるので少しとっつきにくい印象があります。 gcloud auth logingcloud auth application-default loginService AccountApplication Default Credentialsこれらの概念は認証・認可のベースとなっている OAuth2 の文脈で眺めてみると全体像が理解しやすくなるので、本記事でまとめてみたいと思います。 GCP での認証・認可GCP の認証・認可は一部(*)を除いて全て OAuth2 ベースでやり取りされています。(* API Key) OAuth2 は三者間の手続きです。 3-Legged OAuth2Client が Resource Owner の代わりに Resource
JSON Web Token (JWT) - OAuth.jp
@novです。 個人的に最近OAuth 2.0よりJWT (というかJWS) を利用するシーンが多く、毎回同じ説明するのもめんどくさいのでブログにまとめるかと思い、どうせならOAuth.jpに書くかということで、こんな記事を書いております。 （そろそろJWTとJWSは、OpenID Foundation Japanの翻訳WGで翻訳するべき？） JSON Web Token (JWT) とは、JSONをトークン化する仕組み。 元々はJSONデータにSignatureをつけたりEncryptionする仕組みとして考えられたものの、Signature部分がJSON Web Signatue (JWS)、Encryption部分がJSON Web Encryption (JWE) という仕様に分割された。 それぞれ2012年10月26日現在の最新仕様はこちら。 （JWTとJWSは既にだいぶ仕様が固
OAuth 2.0 全フローの図解と動画 - Qiita
RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF
JWS 実装時に作りがちな脆弱性パターン - OAuth.jp
JOSE (Javascript Object Signing and Encryption) 愛で満ち溢れる ID 厨界隈において、燦々と輝く JWS (JSON Web Signature)、美しいですよね！ JWT がジャニーズなら、JWE は EXILE、JWS は石原さとみと言ったところでしょうか？ と、冗談はさておき、JWT をお使いの皆さんは、当然署名付けてますよね？署名検証しますよね？ そんなあなたに一言いいたい！ まだ HMAC で消耗してるの？ いや、決して HMAC オワコンとかは言ってないですよ？スマホアプリでの署名検証のために、アプリに共通鍵埋め込むのはナンセンスってだけで。 ということで、今日は JWS をお使いのみなさんに、実装時に作りがちな脆弱性パターンを2つご紹介します。 今日紹介する脆弱性の2つのうち、1つめは HMAC, RSA, ECDSA のどれを
Big Sky :: コマンドラインアプリで OAuth2 認証を使う際に使えるテクニック
OAuth2 でレスポンスタイプがコードもしくはトークンの場合、ブラウザで認証を行ってコードやトークンを自前サーバで受け取る事になる。モバイルアプリだと組み込みブラウザが前提になっておりリダイレクトの最終 URL からアクセスコードやトークンを得る。ただコマンドラインアプリの場合、認証の為に起動したブラウザの最終 URL を得る方法はない。また1コマンドラインアプリケーションの為にドメイン付きのコールバックサーバを用意するのも面倒だし、作ったサーバをユーザに信用して貰う必要がある。あとそもそも外部のサーバで受け取ったトークンをどうやってコマンドラインアプリに渡すかという問題がある。 そこで使うのがローカルサーバを立てる方法。認証後のコールバック先をコマンドラインアプリから起動したローカルサーバにし、そこにリダイレクトさせてアクセストークンを貰い保存する。 今日はこれが伝わり易い用に Mic
HTTPS でも Full URL が漏れる？OAuth の code も漏れるんじゃね？？ - OAuth.jp
なんですかこれは！ New attack bypasses HTTPS protection on Macs, Windows, and Linux DHCP につなぐと PAC ファイルがダウンロードされて HTTPS であろうとアクセス先の Full URL は漏れるですって？ Web Proxy Autodiscovery ですって？ チョットニホンゴデオネガイシマス ってことで、まぁこれが実際どれくらい簡単に実現できる攻撃パターンなのかは他のセキュリティ業界の方々に後で聞くとして、この記事でも触れられてる OpenID Connect とか OAuth2 への影響について、ちょっとまとめておきましょうか。 Authorization Request & Response が漏れる response_mode=form_post なんていうのも一部ありますが、基本 OAuth2 /
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトー
OAuth / Connect における CSRF Attack の新パターン - OAuth.jp
昨日こんなのが OAuth ML に流れてました。 [OAUTH-WG] Another CSRF attack 前提条件 RP (Relying Party a.k.a. OAuth Client) が2つ以上の IdP (Identity Provider a.k.a. OAuth Server) と連携している状況で、片方の IdP に悪意がある。 悪意ある IdP = AIdP (A は Attacker の略) その他の IdP = HIdP (H は Honest の略) 攻撃フロー Victim が AIdP を使って RP へのログインを試みる。 RP は Authorization Request を AIdP に送る。 AuthZ Req には Browser Session と紐付いた state パラメータをつけている。 AIdP は Victim を認証し、必要に
NIST 800-63C を翻訳しました - OAuth.jp
先日このブログでも紹介した OAuth Revocation, JWK JWK Thumbprint 仕様の翻訳版 に引き続き、OpenID Foundation Japan 翻訳・教育 WG リーダーとしての Nov です。 先日 翻訳 WG の Facebook Page でも告知したように、現在 NIST SP 800-63-3 – Digital Authentication Guideline の翻訳を開始しています。 今日はその中から、すでに翻訳が完了している NIST SP 800-63C – Federation and Assertions のご紹介です。 Level of Assurance プロフェッショナルなみなさまのことです、すでに Level of Assurance とか LoA とかいう単語を耳にしたこともおありでしょう。 NIST SP 800-63 は、
OAuth2 のフローを Alloy Analyzer でモデリングする - 詩と創作・思索のひろば
趣味でウェブの認証 API を地力で設計しようとしていたときに、認証フローの仕様を頑張ってこしらえたとして、その正しさをどうやって保証するんだろう？ と疑問に思い、調べていたところ、「形式手法」というのに行き当たった。 形式手法というのはシステムの正しさを上流工程から検証するための方法で、数理論理やロジックに基づいている。その中でも厳密な仕様定義を求める方向と自動検証を求める方向とあるらしいが、Alloy はその後者に位置づけられ、軽量形式手法と呼ばれるもののひとつだということらしい。Alloy はモデリングのための言語および実行環境で、以下のホームページから入手できる。 http://alloy.mit.edu/alloy/ インターネット上にチュートリアルやマニュアルもあるが、作者による教科書の邦訳が出ていて、これで勉強してみた。 抽象によるソフトウェア設計−Alloyではじめる形式手
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
認証は単純な概念で、別の言葉で言えば本人確認です。Web サイトにおける本人確認の最も一般的な方法は ID とパスワードの組を提示してもらうことですが、指紋や虹彩などの生体情報を用いた本人確認方法もありえます。どのような確認方法だとしても (ワンタイムパスワードを使ったり、2-way 認証だったりしても)、認証とは、誰なのかを特定するための処理です。開発者の言葉でこれを表現すると、「認証とは、ユーザーの一意識別子を特定する処理」と言えます。 一方、認可のほうは、「誰が」、「誰に」、「何の権限を」、という三つの要素が出てくるため、複雑になります。加えて、話をややこしくしているのは、この三つの要素のうち、「誰が」を決める処理が「認証処理」であるという点です。すなわち、認可処理にはその一部として認証処理が含まれているため、話がややこしくなっているのです。 認可の三要素をもう少し現場に近い言葉で表
Authlete を使って超高速で OAuth 2.0 サーバー & API サーバーを立てる - Qiita
Authlete を利用して, 超高速で OAuth 2.0 サーバー & API サーバーを立てる方法を解説する. 対象読者 OAuth 2.0 の基本的な概念 (アクセストークン, 認可コードフロー, 認可エンドポイント, トークンエンドポイント等) を大体把握している人 (もしカスタマイズしたいなら) Java 屋さん 所要時間 5~10 分 システム構成 構成は下図の通り. また, 今回は以下のようにダミー情報を用いることに注意. エンドユーザー情報 → 認可サーバー内に定義されたダミー情報 リソース → リソースサーバー内に定義されたダミー情報 手順 手順は以下の通り. Authlete にサインアップ 認可サーバーのセットアップ リソースサーバーのセットアップ 動作確認 1. Authlete にサインアップ 1.1. サインアップ こちらから, Authlete にサインアッ
GitHub - dexidp/dex: OpenID Connect (OIDC) identity and OAuth 2.0 provider with pluggable connectors
Go言語の練習用にTwitterのOAuth認証をフルスクラッチしてみた - Qiita
何となく気が向いたので昨日はじめたばかりのGo言語で練習がてら書いてみました。JSONのレスポンスはエラーチェック用にしか行っておらず、正常時はそのまま文字列として返します。しかも奇形レスポンスのチェックは省いているのでかなり手抜きです。でも標準パッケージしか使ってないからいいんだ、うん！ /** * GO is GOD */ package goisgod import ( "fmt" "time" "sort" "strings" "crypto/hmac" "crypto/rand" "crypto/sha1" "encoding/base64" "encoding/json" "net/http" "net/url" "io/ioutil" ) /** * クレデンシャルを保持する構造体 */ type OAuth struct { ConsumerKey string Consu
モバイルアプリのユーザ認証方法についてまとめてみた - Qiita
追記 (2018-10-08) 4年以上前に書いた記事ですが、Access Token として JWT を利用することは非推奨なようなので、お詫びして修正致します。 参考: どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ 概要 みんなやってるはずなんだけど、あまりまとまった情報がなかったので書いてみます。認証周りはセキュリティを気にして、みんな書きたがらないのかな？それとも私の調べ方が悪かっただけ？マサカリお待ちしてます。 認証の基本方針 +--------+ +--------+ | | | | | |----(1) Credential ------------>| | | | | | | |<---(2) Access Token -----------| | | | | | | Client | | Server | | | | | | |----(3)
gateを使って手軽に認証を導入する - pixiv inside [archive]
ISUCON4 で準優勝した @catatsuy です。 賞金の使い道はまだ考えていません。 ところでピクシブ株式会社では冬インターンをやります！ エンジニア向け pixiv開発のbugリストからの脱出！エンジニア職インターン - ピクシブ株式会社 採用サイト ISUCON4 の予選問題を解くだけでインターンに参加できるチャンスなのでぜひ挑戦してみてください！！1 pixiv/intern2014w この記事は当初はアドベントカレンダーの記事にする予定でしたが，今が旬だと圧力をかけられたので今公開します。 なおこの記事は ピクシブ株式会社 Advent Calendar 2014 - Qiita の -17 日目の記事です。 今までの社内ツールの認証は各サーバーに設定されていたために退職者などの対応が非常に大変でした。そこで最近のピクシブ株式会社では typester/gate を導入する
![gateを使って手軽に認証を導入する - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/f234db5d7f70f2a8afe476e78ede9c5167fc67c1/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fc%2Fcatatsuy%2F20141114%2F20141114192037.png)
認証機能のないアプリケーションでOAuth2認証を提供する - 弥生開発者ブログ
こんにちは、@Dominion525 です。 好きなモビルスーツはMS-06R-1高機動型ザクIIです。 ちょっとしたダッシュボードとか気の利いたOSSのWebアプリケーションなどを動かすときに、気になるのは認証周りです。 都度、関係者分のアカウントを管理したり、パスワードの個別に変更したりするのは大変に面倒です。 こういうのはアプリケーション本体ではなくフロントのリバースプロキシで制限すると便利です。 ただし、基本認証などでは心もとないのでもう少し工夫をしてみます。 (もちろん、対象のアプリケーションは localhost からしかアクセス出来ないようになっているものとします。) mod_auth_openidc そこで、OAuth2認証を提供してくれる素敵Apacheモジュール*1が mod_auth_openidc です。*2 弊社では Google Apps を利用しているので、メ
Passport - Node.jsのための、シンプルで使いどころを選ばない認証モジュール
Passportとは？ PassportとはNode.jsのための認証機能を提供するミドルウェアです。 ExpressベースのWebアプリケーションで簡単かつ柔軟に利用でき、使いどころを選びません。 Facebookやtwitter、または通常のユーザID/パスワード認証など、多彩なサービスの認証に対応しています。 説明を読む » 機能 140を越える認証ストラテジー OpenIDやOAuthを使ったシングルサインオン 単純化された認証成功・失敗時処理 継続するセッションのサポート 動的なスコープおよび権限管理 認証ストラテジーを選ぶだけで動作可能 認証ストラテジーの拡張・独自実装が可能 簡単に始められる 軽量な実装コード $ npm install passport
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - movableink/doorman: HTTP Proxy + OAuth
GitHub - bitly/oauth2_proxy: A reverse proxy that provides authentication with Google, Github or other provider
