世界一わかりみの深いOAuth入門
![世界一わかりみの深いOAuth入門](https://cdn-ak-scissors.b.st-hatena.com/image/square/c1df9cb64d04ab8d93681784323e2608a802a276/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F58c098ba99bf45d78d239a773c78df8e%2Fslide_0.jpg%3F18056568)
はじめに OAuth 2.0 のフローをシーケンス図で説明したWeb上の記事や書籍を何度か見かけたことがありますが、 フローの概要に加え、クライアントや認可サーバー側でどういったパラメータを元に何を検証しているのかも一連のフローとして理解したかった RFC 7636 Proof Key for Code Exchange (PKCE) も含めた流れを整理したかった というモチベーションがあり、自分でシーケンス図を書きながら流れを整理してみた、という趣旨です。 記事の前提や注意事項 OAuth 2.0 の各種フローのうち、認可コードフローのみ取り上げています 認可コードフローとはなにか、PKCE とはなにかという説明は割愛しています 概要について、個人的にはこちらの動画が非常にわかりやすかったです: OAuth & OIDC 入門編 by #authlete - YouTube 認可コードフ
Ejiro Asiuwhu Software engineer with a drive for building highly scalable and performant web applications. Heavily interested in module federation, micro frontends, state machines, TDD, and system designs. Big on web performance and optimization, advanced component design patterns, a11y, SSR, SSG, ISR, and state management. Expert at crafting highly reusable TypeScript-heavy component libraries. E
OAuth 2.0 Security Best Current Practice Abstract This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0.¶ Status of This Memo This Internet-Draft is submitted in full confor
In the “stone age” days of the Internet, sharing information between services was easy. You simply gave your username and password for one service to another so they could login to your account and grab whatever information they wanted! Yikes! You should never be required to share your username and password, your credentials, to another service. There’s no guarantee that an organization will keep
“OAuth/OIDC Component as a Service” Authlete's APIs are carefully crafted to focus on the core of OAuth 2.0 / OpenID Connect (OIDC). You can choose to build a complete OAuth/OIDC server with Authlete, or simply integrate Authlete with existing service components such as identity and access management (IAM) and API gateways. Just Forward OAuth/OIDC Requests to Authlete You don't have to evaluate cl
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
(新元号が発表されましたね。いらすとや さん仕事早い.....!) 新社会人・学生の皆さま、御入社・御入学おめでとうございます! はじめまして。プラットフォーム事業本部の Kikuchi です。 普段は Cloud IoT OS のアカウント管理・認証・権限管理周りの機能検討や設計・開発をやっています。 主な開発言語 は Rust ではなく Ruby です。 Object#tap とか可愛いですよね。 さて、少し前のことですが、OpenID TechNight #16 ~ OpenID Connect 5周年記念 というイベントで、「OPTiM サービスでの OAuth 2.0/OpenID Connect と周辺技術の活用事例」というテーマで Lightning Talks をさせていただきました。 LT ということもあり時間が限られていたため、今回はネタ落ちした内容をご紹介していこうか
OpenID Connect概要 OpenID Connectをひと言で説明すると、 OAuth 2.0 + Identity Layer = OpenID Connect という表現が最もふさわしい。 OpenID Connectは、「OAuth 2.0を使ってID連携をする際に、OAuth 2.0では標準化されていない機能で、かつID連携には共通して必要となる機能を標準化した」OAuth 2.0の拡張仕様の一つである。 OpenID Connect登場以前は、OAuth 1.0/2.0ベースのID連携の仕組みがTwitterやFacebookなどの巨大SNSから提供され、人気を博した。これらの仕組みは今でも広く利用されている。 一方で、OpenID Connectの1つ前のバージョンのOpenID 2.0では、ID情報の連携はできるもののAPI連携には利用できないなど、デベロッパーに強
Integrate 100+ OAuth providers in minutes. Setup your keys, install oauth.js, and you are ready to play !
bitly/oauth2_proxyを用いて,ウェブアプリケーションに手っ取り早くOAuth2認証を導入するという話です. oauth2_proxyは良い感じでOAuth2による認証を肩代わりしてくれる君で,何らかのリバースプロキシの認証機構と組み合わせて利用すると簡単にOAuth2ログインを実現することができます. 今回は例としてKibanaにGoogleのOAuth2ログインを導入してみたいと思います. 構成 Kibana bitly/oauth2_proxy nginx +------+ +-------+ +--------------+ +--------+ | | | | ----auth----> | | | | | user | --request--> | nginx | | oauth2_proxy | <--auth--> | Google | | | | | <--
A quick note — all of my future posts will be published on my dedicated website and this publication is no longer being updated. Thanks for reading! As much as I love open source software, I think an angel gets its wings whenever Cupertino & Friends™ obsoletes a library in any of my projects. The thrill of deleting something in a pod file generally exceeds the initial glee one might experience whe
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
みなさまご無沙汰しております。 毎年、4月1日には、ジョークだけど実は使えるかもな規格を書こうとしているのですが、今年も書けずにいつの間にやら4月も3分の1が過ぎてしまいました。結局のところ、今年は何に忙しくしていたかというと、OAuthで「記名式」トークンを使う方法を規格化しようとしていて時間が経ってしまいました。 「記名式」って何のことやらと思いますよね?説明しましょう。 通常のOAuthのトークンは「ベアラ(bearer)・トークン」と言います。ベアラ(bearer)とは、「bear (持ってきた)+ er(人)」ですので、「持参人」となります。トークンも日本では馴染みのない単語ですが、これは「切符」のことです。昔の地下鉄などでは、切符の代わりに「トークン」というコインを改札機に入れて通過していました。今でもトロントの地下鉄などはそうです。ですから、ベアラ・トークンと言うと難しく感じ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く