OAuthの言葉周りを整理する
OAuthの仕組みとToken認証周りの言葉はいつまで経ってもはっきり理解できないものの一つでした。 しかし最近ようやく理解できるようになってきたのでとりあえずそれぞれの言葉の指すものや定義をここで整理してみようと思います。 リフレッシュトークン リフレッシュトークンとは アクセストークンの有効期限が切れたときに、認可サーバーにアクセストークンの更新リクエスト認証をするためのトークン。 OAuth自体はリフレッシュトークンがなくとも実装できるが、リフレッシュトークンはOAuthをより便利にするためのもの。 一般的に有効期限は長い。 ないとどうなるのか アクセストークンの期限が切れたらその度にSNS認証のあのログイン画面に飛ばされてメアドとパスワードの入力が必要になる。 セキュリティに関すること 有効期限が長くても安全性に問題がないと考えられる理由としては、アクセストークンの期限切れ時にしか
雰囲気でOAuthを使っていたエンジニアがOAuthサーバ(RFC6749)を自作してみる
はじめに Auth屋さんの本やその他有識者のBlogなどを読むことで少しながらOAuthやOIDCの仕組みが理解できてきました。 そんななかで以下の記事が大変勉強になりました。 ↑の記事ではRubyで実装されているのですが、これを参考というかほぼ丸コピですがgolangで実装してみたいと思います。 コードは以下にあります。 仕様 OAuthサーバでは認可エンドポイントとトークンエンドポイントを実装する必要があります。 認可とトークンエンドポイントの2つに加えてユーザ認証を行うエンドポイントを作ります。 今回は元記事と同じようにFormに入力したユーザ&パスワードを受け取り確認します。 RFC6749に関する仕様は元記事の2.注意点と同じになるはずです。 「はずです」というのは恥ずかしながらまだ完全な理解に至っておらず今もRFCを読みながら答え合わせ中です。 ぜひ認識違いがあればご指摘くださ
オープンソースかつ自サーバー上でホスト可能な認証プラットフォーム「SuperTokens」が登場
ウェブサイトにログイン機能を実装できるサービスとしてはAuth0やAmazon Cognito、Firebaseがありますが、いずれもオープンソースではありません。ニュースサイト・Hacker Newsを運営するYコンビネータの支援のもと、オープンソースとして開発された「SuperTokens」は、Auth0やAmazon Cognitoなどの代替を目指すソフトウェアです。 SuperTokens, Open Source Alternative to Auth0 https://supertokens.io/ アクセス可能なリソースをアプリケーションに柔軟に割り当てることができる「OAuth」は、多くのウェブサイトが準拠している「権限の認可」を行うための標準規格です。OAuthはAuth0やAmazon Cognito、Firebaseといった認証プラットフォームを利用することでソフトウ
OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう
note のやらかしのあのへんについて。 認証自作、 Rails 、 Devise - Diary パーフェクト Rails 著者が解説する devise の現代的なユーザー認証のモデル構成について - joker1007’s diary 認証サーバーの実装は本質的に難しいです。セキュリティが絡むものは「簡単な実装」などなく、プロアマ個人法人問わず、個人情報を守るという点で、同じ水準を要求されます。悪意あるハッカーは常にカモを探していて、もし認証が破られた場合、自分だけではなく大多数に迷惑が掛かります。初心者だから免責されるといったこともありません。全員が同じ土俵に立たされています。 とはいえ、認証基盤を作らないといろんなサービスが成立しません。そういうときにどうするか。 Firebase Authentication で、タイトルの件なんですが、 Firebase Authenticat
アプリで「ログインしっぱなし」はどのように実現されているか？ - Qiita
このツイートを見て、「アプリで再ログインを頻繁要求されるってユーザビリティ良くないな。」と思ったのですが、普段裏側の仕組みは意識していなかったりテックリードの方に任せきりだったりしていたので、これを機に調べてみました。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) 2019年7月8日 この記事は「アプリでログインしっぱなしは、どのように実現されるの？」という疑問と調べた結果を共有するために書いていきます。 間違いや「もっとこんな仕組みが使われてるよ！」等のツッコミがあれば、どしどし貰えると助かります！ 疑問1. アクセストークンという仕組みとは？ 「なぜアクセストークンという概念が必要なのか？」 モバイルアプリでユーザー認証をし
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
OAuth 2.0 の勉強のために認可サーバーを自作する - Qiita
逆に、RFC 6749 以外で定義されている認可フローをサポートする場合、新たに別のエンドポイントの実装が必要になることがあります。例えば CIBA（Client Initiated Backchannel Authentication）ではバックチャネル認証エンドポイント（backchannel authentication endpoint）、デバイスフロー（RFC 8628）ではデバイス認可エンドポイント（device authorization endpoint）の実装が求められます。 この記事では、認可エンドポイントとトークンエンドポイントを実装します。サポートする認可フローは認可コードフローのみ、サポートするクライアント・タイプはパブリックのみとします。 2. 注意点 下記の理由、および書かれていないその他の理由により、本実装は商用利用には適していません。 セキュリティー上必須
authorization_code_flow
authorization_code_flow ~"�jU @startuml UA -> App: /login UA <-- App: Redirect UA -> 認可サーバー: /auhorize UA <- 認可サーバー: ログインページ表示 UA -> 認可サーバー: ログイン UA <- 認可サーバー: 認可（AppにXXXを許可しますか？ UA -> 認可サーバー: OK UA <-- 認可サーバー: Redierct UA -> App: /callback?code=xxx&state=xxx App -> 認可サーバー: /token に認可コードを渡す App <- 認可サーバー: AccessToken App -> App: セッションにAccessToken保存 UA <- App: ログイン完了 @enduml bad_practice_authorizat
OAuth 2.0 PlaygroundでOAuth 2.0のクライアントの気持ちになろう | DevelopersIO
OAuth 2.0に対応したAPIクライアントのアプリを書きたい気持ちになったのですが、テストをどうするか考えながらOSSの認可サーバーをローカルに立てたりするかなど考えていたら、OAuth 2.0 Playgroundというものを知りました。 こちらは実際に認可サーバーを使ってOAuth 2.0 のクライアントの気持ちになれるチュートリアルで、良さそうだったので紹介します。 OAuth 2.0 Playground okta社によって提供されている、OAuth 2.0 とOIDCのフローを、実際に体験するためのチュートリアルです。 Authorization Code PKCE Implicit Device Code OpenID Connect に対応しており、実際に認可サーバーを叩きながらインタラクティブに学ぶことができます。 やってみる 今回はAuthorization Code
OAuth 2.0 クライアント認証 - Qiita
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
ユーザーをログアウトから守れ！―シーケンス図から読み解くログイン状態維持【Mobileアプリ編】 | DevelopersIO
認証というのは面倒なもので、利用者に余計な手間を掛けさせてアクティブ率を下げたくないと日夜工夫を凝らす我々にとっては、やり玉に上がりやすいテーマであると思います。要するに、ユーザーをログアウトさせたくないわけです。さて、どうしましょう？ 生魚おじさん、都元です。今日の魚はワラサです！ 出世魚であるブリのちっちゃいヤツです！ 今回はユーザーをログアウトから守れ！―シーケンス図から読み解くログイン状態維持【Webアプリ編】と対になる、Mobileアプリ編をお送りします。 さて、認証というのは面倒なもので、利用者に余計な手間を掛けさせてアクティブ率を下げたくないと日夜工夫を凝らす我々にとっては、やり玉に上がりやすいテーマであると思います。要するに、ユーザーをログアウトさせたくないわけです。(再掲) 例えば Facebook や Twitter のモバイルアプリはいつ起動しても自分のアカウントでロ
OAuth アクセストークンの実装に関する考察 - Qiita
はじめに この記事では、OAuth 2.0 のアクセストークンの実装に関する考察を行います。本記事の執筆者本人による動画解説も『OAuth & OIDC 勉強会 【アクセストークン編】』で公開しておりますので、併せてご参照ください。 English version of this article is here → "OAuth Access Token Implementation". 1. アクセストークン実装方法の分類 OAuth のアクセストークン※１の実装方法は認可サーバーの実装依存です。 実装依存ではありますが、RFC 6749 の『1.4. Access Token』にある次の記述が示唆するように、 The token may denote an identifier used to retrieve the authorization information or may
マイクロサービス時代のSSOを実現する「Keycloak」とは
本連載では、近年注目されている認証プロトコル「OpenID Connect」をサポートするオープンソースのシングルサインオン（SSO）ソフトウェア「Keycloak」の活用方法を解説していきます。第1回目は、APIにおける認証／認可の仕組みとKeycloakの概要を紹介します。 連載目次 APIにおける認証／認可の仕組み 近年、金融や流通分野で注目されている「APIエコノミー」や「マイクロサービスアーキテクチャ」などの登場により、サービスの機能を「REST API」として提供することが当たり前になってきています。そして、REST APIを公開するためには、誰がアクセスしてきたのかを確認するための「認証（Authentication）」と、APIへのアクセスを誰に許可するのかという「認可（Authorization）」の仕組みが不可欠です。 しかし、複数のサービスがそれぞれ個別に認証／許可を
インフラエンジニアが一切コードを書かずにWebサーバーに認証機能を実装した話 ｜ Developers.IO
コンニチハ、千葉です。 AWSのサービスを組み合わせれば、独自の認証基盤を構築できます。例えば、WordPressを限定的に公開する、Apache、 Nginx、カスタムWebアプリなどなど、簡単に認証をかけたい場合、ベーシック認証は昔から利用されてきました。ただし、これはスケーラビリティや運用面でどうしてもつらい場面がでてきます。 そこで、ALBに素敵すぎる組み込みの認証機能が追加されたのでこちらを利用し、コードを一切書かずに認証を導入します。また、OIDCなど認証プロトコルに対応していますが、今回はシンプルにCognitoのユーザープールを利用し、ユーザー管理自体もCognitoに任せます。 要件 今回の想定する要件です。 Nginxを社内ユーザーのみに公開 スタンドアローンのユーザープールを用意(AD、OICD、SAMLなどによる連携なしで、独自でユーザーを管理) ユーザーは管理者が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
