oauth2とは何か？認証と認可の違い。
あぁ、しくじった。毎日書こうとしたら休みの日である事を完全に忘れてゲームばかりした結果 0時を回って書いてしまっている。 しかも今回の内容が多分長くなりそうだから既に明日やる口実を作って明日作成しようとしている。 あぁ、憂鬱だ。 そんな始まり方のoauth 最近でこそoauth認証って普及されてますけど、 最初見た時、？？？ってなりませんでしたか？ 僕は謎過ぎて良くわからなかったから、こんなのやらないと思ってました。 が、、、今になってみるとあまりにも便利が故に もはや、Googleサインインとかappleサインインが無いと嫌ですもんね。 おいおいおい、入れておけや。と。。。 それだけ楽にしてくれた認証機能ですが、 実は、認証機能以外にも認可という部分もあるので 今日はその辺を自分の備忘録的に書いていこうと思っています。 参考にしたもの まず先に参考にした動画を貼ります。 ざっくりと簡単に
Create Custom Grant Token in Laravel Passport
You already know that OAuth 2.0 protocol is used for authentication and authorization. Laravel has Passport, which is a full Oauth 2.0 server implementation, used for authentication over API. By default, Laravel Passport has 4 types of Grants. Authorization CodeImplicitPasswordClient CredentialsBut unfortunately, for project purposes, we may need custom grants. I had to make a custom grant in my l
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
Auth0を利用してOAuth 2.0のPKCEを理解する | DevelopersIO
Auth0を利用してPKCEを一緒に試しつつ、理解していきましょう。本記事ではPKCEを実際に試してみて、理解できることをゴールに書いていきます。 はじめに みなさま。はじめまして、Auth0社の筒井です。ソリューションアーキテクト・テクニカルアカウントマネージャーとして主にAuth0のEnterprise版をご契約頂いたお客様に対して技術支援を行っています。今回はゲストブロガーとして投稿します。 Auth0を利用してPKCEを一緒に試しつつ、理解していきましょう。PKCEはすでに様々なところで詳細に説明されているので、ご存知の方も多いと思います。 本記事ではPKCEを実際に試してみて、理解できることをゴールに書いていきます。 さっそくですが、PKCEって何でしょうか？ PKCEは、Proof Key for Code Exchangeの略で、呼び方はピクシーと呼びます。RFC 7636と
【読書メモ】「成長する企業はなぜ SSO を導入するのか」 - ROXX開発者ブログ
この記事は個人ブログと同じ内容です 【読書メモ】「成長する企業はなぜ SSO を導入するのか」 --- 最近チームのメンバーが誕生日で、よくバラエティ番組で流れる曲「Happy Birthday - Stevie Wonder」が頭から離れない sekitats です。 今月は個人的に認証について学ぶ月間で、本を3冊読みました。認証周りわからんことばかりだったので。 「雰囲気で使わずきちんと理解する！整理して OAuth2.0 を使うためのチュートリアルガイド (技術の泉シリーズ（NextPublishing）) Auth 屋」 「「Auth0」で作る！認証付きシングルページアプリケーション (技術の泉シリーズ（NextPublishing） 土屋 貴裕) 「成長する企業はなぜ SSO を導入するのか」日本ヒューレット・パッカード株式会社 OAuth については、別記事を書いてみたのでそち
GitHub Actions: Secure cloud deployments with OpenID Connect
October 27, 2021 GitHub Actions now supports OpenID Connect (OIDC) for secure deployments to cloud, which uses short-lived tokens that are automatically rotated for each deployment. This enables: Seamless authentication between Cloud Providers and GitHub without the need for storing any long-lived cloud secrets in GitHub Cloud Admins can rely on the security mechanisms of their cloud provider to e
SAML入門
【累計3500部突破（商業版含む）🎉】 SAMLaiの道は果てしなく険しい。 本書では、SAML2.0で一般的に多く使用されるフローであるWeb Browser SSOのSP-initiatedとIdP-initiatedと呼ばれるものを中心に、SP側の目線でなるべく簡潔に解説します。 SAML認証に対応してほしいと言われても、もう頭を抱える必要はありません。 筆者自身も何もわからない状態からもがき苦しみながらSAML SPを実装し、数年間サービスを運用してきました。 そのつらい経験を踏まえて、SPを実装する上で今まで触れられることのなかった ・どういう設計が必要か？ ・何を気をつけなければならないか？ のエッセンスを詰め込みました。 SAMLはエンタープライズ用途では求められることが非常に多く、歴史もそれなりに長いものですが、実装する上で必要な体系的な情報はなぜかほとんどありません。
アクセストークンをWebWorkerで扱う - console.lealog();
というアプローチを紹介してる記事があって、なるほど？と思ったのでまとめてみる。 元記事はこちら。 Leveraging Web Workers to Safely Store Access Tokens – The New Stack 毎度のことながら、今にはじまったことではない。 元記事いわく WebWorkerであれば、メインスレッドで実行されるであろうXSSや3rdのコードから触れないので安全！ 設計としては、 メイン: まず`Worker`をロード メイン: 初期化のメッセージを`postMessage()` クレデンシャルがあるならそれを渡す ワーカー: アクセストークンの準備 受け取ったやつ or そこで`fetch()`して、オンメモリに保存 （これで準備OK） メイン: APIにリクエストしてほしいと`postMessage()` ワーカー: APIに向けてアクセストークン
Auth0 導入編 | フューチャー技術ブログ
始めに様々なシステムを構築する中で必ず発生する要素 ログイン そのログインを支える技術要素 認証・認可 しかし、認証認可の壁は無駄に高く、調べ始めるとまずは数々の専門用語に阻まれ BASIC認証・OAtuh・OpenID・Jwt・Jwk・Jwe… 次に、認証Flowに阻まれます。 Implicit Flow、Client Credentials Flow…etc これらを比較的容易に実装する、Auth0を紹介していきます。 なぜ今回の連載がAuth0なのか？社内で以下の要件を持つ案件が複数あり、結果としてそれぞれでAuth0を採用・知見が溜まったため、連載という形をとることにしました。 OIDC(OpenIdConnect)準拠の要件 Google/Facebookなどのソーシャル連携の要件 開発の期間が短い メンテナンス費用は抑えたい 認証認可の実現方式とAuth0の立ち位置実現方法は大
インフラエンジニアが一切コードを書かずにWebサーバーに認証機能を実装した話 ｜ Developers.IO
コンニチハ、千葉です。 AWSのサービスを組み合わせれば、独自の認証基盤を構築できます。例えば、WordPressを限定的に公開する、Apache、 Nginx、カスタムWebアプリなどなど、簡単に認証をかけたい場合、ベーシック認証は昔から利用されてきました。ただし、これはスケーラビリティや運用面でどうしてもつらい場面がでてきます。 そこで、ALBに素敵すぎる組み込みの認証機能が追加されたのでこちらを利用し、コードを一切書かずに認証を導入します。また、OIDCなど認証プロトコルに対応していますが、今回はシンプルにCognitoのユーザープールを利用し、ユーザー管理自体もCognitoに任せます。 要件 今回の想定する要件です。 Nginxを社内ユーザーのみに公開 スタンドアローンのユーザープールを用意(AD、OICD、SAMLなどによる連携なしで、独自でユーザーを管理) ユーザーは管理者が
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
OAuth2.0の備忘録的まとめ - Ari-Press
Web系技術を学ぶ上で，やはりセキュリティ周りの技術は外せません。OAuth1.0ならばTwitter APIを触っていたんですが、、いつの間に2.0に！ということで、頑張って仕様書を読みつつ自分なりにまとめてみました。 The OAuth 2.0 Protocol draft-ietf-oauth-v2-10 を参考にしています。 また、以下で特に明示されない引用部分は全て The OAuth 2.0 Protocol draft-ietf-oauth-v2-10 から引用したものとします。 更に、以下の文章は2012/12/28時点でのAriの理解をまとめたものであり、内容を保証するのはこの時点でのAriの読解力のみです。 OAuth2.0の必要性 通常、ログインが必要なサービスを利用する際はログインID/パスワードの情報が必要になります。 特定のWebサービスに必要な時にアクセスする
RFCとなった「OAuth 2.0」――その要点は？
RFCとなった「OAuth 2.0」――その要点は？：デジタル・アイデンティティ技術最新動向（2）（1/2 ページ） いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サー ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。 再び、デジタル・アイデンティティの世界へようこそ 前回「『OAuth』の基本動作を知る」ではOAuthの仕様がどういうものかについて説明しました。今回は引き続き、 OAuth 1.0とOAuth 2.0の違い OAuth 2.0をセキュアに使うために知っておくべきこと について述べていきます。 OAuth 1.0とOAuth 2.0の違い クライアントタイプの定義 OAuth 2.0では、O
Github APIを使ってOAuth2を理解してみる - techium
OAuth2で認証し、Githubのデータにアクセスしてみましょう。 ライブラリなどを使うと簡単にアクセスすることはできると思いますが、その中で何をやっているかを理解するためにブラウザとcurlを使って通信し、手動で一つ一つ動作せてみましょう。 OAuthの特徴はパスワードを知ることなく特定のサービスのデータを取得や操作ができるようにできることになります。 そのためにやらないといけないこととしては次の事になります。 OAuth アプリケーションの登録 認証 アクセストークンの取得 データアクセス データへアクセスするためにはデータアクセスまでに次の情報を集める必要がああります。 Client ID Client Secret code アクセストークン これらの情報を収集することができればデータのアクセスが可能です。 それぞれのデータの取得方法についてご説明します。 OAuthアプリケーシ
OAuthプロトコルの中身をざっくり解説してみるよ - ( ꒪⌓꒪) ゆるよろ日記
「おーおーっすっ!」 てなこって、TwitterのAPIのBASIC認証も6月末に終了してOAuth/xAuthに移行するというこの時期に、あらためてOAuthについて勉強してみたんですのよ? OAuth認証を利用するライブラリは各言語で出そろってきてるのでそれを使えばいんじゃまいか? というと話が終わるので、じゃあそのライブラリの中身はなにやってんのよってことを、OAuthするScalaのライブラリ作りながら調べたことをまとめてみました。 間違っているところもあると思うのでツッコミ歓迎です＞＜ OAuthってそもそもなんなの? ものすごくざっくりというと「API利用側が、ユーザ認証をAPI提供サービス側にやってもらうための仕様」って感じでしょうか? BASIC認証の場合、API利用側が認証に必要なアカウントやパスワードを預かる必要があるわけです。悪意のあるAPI利用側が「なんとかメーカー
OAuth:フロー - Yahoo!デベロッパーネットワーク
指定されたURLは存在しません。 URLが正しく入力されていないか、このページが削除された可能性があります。
OAuth2.0サーバを素早く立てるライブラリ・フレームワークまとめ | NTT Communications Developer Portal
認証を行うAPIとしてはOpenIDが有名なのですが、認証だけであるためにメールアドレスの取得であったり、その後のシステム連携に繋げられないといった不満があります。そこで認証と委譲を行うOAuth（特に1.0の問題点を解決したOAuth2）を使うのが一般的になっています。 そこで今回は既存のシステムはもちろん、今後作られるシステムでも手軽にOAuth2の機能が追加できるライブラリを紹介します。 PHP bshaffer/oauth2-server-php 特に依存のないOAuth2サーバです。既存システムと並列して疎結合で立てるのが良さそうです。 thephpleague/oauth2-server こちらも独立型ですが、CakePHP3やLaravelとの連携も想定されています。 lucadegasperi/oauth2-server-laravel Laravelフレームワーク用のOA
OAuth 1.0 のほうが OAuth 2.0 より安全なの？ - Qiita
1. OAuth 2.0 and the Road to Hell OAuth 1.0 と OAuth 2.0 の違いを調べていると、そのうちに「OAuth 2.0 and the Road to Hell」(by Eran Hammer氏) という文書にたどり着きます。この文書は、OAuth 仕様策定作業で精力的に頑張っていた方が OAuth 2.0 を批判して怒りの脱退宣言をするという衝撃的な文書です。 「OAuth 2.0 は OAuth 1.0 よりも安全ではない」というのが彼の一番の主張です。そのため、OAuth サーバーの実装を検討している人がこの文書を読むと、OAuth 2.0 の採用をためらい、OAuth 1.0 の方を選択してしまうことがあります。 実際、Open Bank Project というプロジェクトの実装である OBP-API では、Wiki で次のように述べて
一番分かりやすい OAuth の説明 - Qiita
はじめに 過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。Authlete アカウント登録はこちら！ ※2：そして２回目の資金調達！→『AUTHLETE 凸版・NTTドコモベンチャーズ・MTIからプレシリーズA資金調達』(2018 年 2 月 15 日発表) 説明手順 （１）ユーザーのデータがあります。 （２）ユーザーのデータを管理するサーバーがあります。これを『リソースサーバ
Railsの第4世代認証エンジンDeviseのREADMEを翻訳してみた - babie, you're my home
Devise の README は懇切丁寧だが、その分クソ長いので、読むのに疲れる。後続のために訳してみることにした。無保証。OAuth2 の部分は飛ばした。長いし。差し迫ったら訳します。 Devise Devise は Warden をベースにした Rails のためのフレキシブルな認証ソリューションです。 Rackベース Rails エンジンに基づいた完全な MVC ソリューション 1回の認証で複数のロールを持たせることができます あなたが必要な部分だけ使えるモジュラー構造というコンセプトに基づいています 以下の11のモジュールで構成されています： Database Authenticatable ユーザーがサインインする時に認証するためにパスワードをデータベースに暗号化し保存します。この認証は POST リクエストまたはBasic認証を通して行われます。 Token Authenti
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
