見出し画像

Streamlit Login機能実装 早速試してみた Python GoogleCloud

Fuji

streamlit 1.42.0でログイン認証機能が公式リリース！ってことで
とりあえずお試しでst.loginを使ってみたかったので実装してみた。
※セキュリティ関連の設定はわからないからすっ飛ばしている

環境構築

  1. GoogleCloudで「APIとサービス」の「認証情報」を開く

2.「同意画面を構成」をクリック

3.以下のような画面になるので「開始」をクリック

4.アプリの情報を入れる
※練習だから今回サポートメールは自分のGmailのアドレスにした

5.「対象」は外部

6.APIとサービスで「OAuth同意画面」を開く

7.「対象」を開く

8.画面をスクロールして「テストユーザー」で「+ADD USERS」をクリック

9.自分のGmailアドレスを入力する

10.「APIとサービス」から「認証情報」を開き上部にある「+認証情報を作成」をクリック

11.「OAuthクライアントID」をクリック

12.「アプリケーションの種類」から「ウェブアプリケーション」を選択する

13.名前を適当にいれる

14.下部にある「承認済みのリダイレクトURI」で「+URIを追加」をクリックして「http://localhost8501/oauth2callback」を入れる

15.「作成」をクリックすると以下の画面が出るので、クライアントIDとクライアントシークレットを何かしらにコピペしてメモしておく

Streamlitアプリを作る

構成

sample
├── .streamlit
│   └── secrets.toml
├── main.py
└── pyproject.toml #なくてもOK

main.py

# Streamlitアプリ main.py （Googleログインのみ）
import streamlit as st

if not st.experimental_user.is_logged_in:
    if st.button("Log in with Google"):
        st.login()  
        st.stop()   # リダイレクト実行のためこれ以降の処理を停止
else:
    st.write(f"こんにちは、{st.experimental_user.name}さん！")  # ログイン済みユーザー名の表示​:contentReference[oaicite:57]{index=57}
    if st.button("ログアウト"):
        st.logout()

secrets.toml 

[auth]
redirect_uri = "http://localhost:8501/oauth2callback" # 14.で設定したやつ　テスト環境用
cookie_secret = "後述します"
client_id = "さっきメモしたクライアントID"
client_secret = "さっきメモしたクライアントシークレット"
server_metadata_url = "https://accounts.google.com/.well-known/openid-configuration"

※server_metadata_urlについては後述

1.cookie_secretを作成する
pythonで作るなら標準モジュールのsecretsを使って作れる

import secrets

cookie_secret = secrets.token_hex(32)  # 32バイトの安全なランダム文字列
print(cookie_secret)

出力した文字列を"cookie_secret ="に設定する

macOSなら（Linuxとかもできる・・・はず）

openssl rand -hex 32

ってコマンド打つと文字列出てくるので、それを"cookie_secret ="に設定すると良い

Authlibライブラリーのinstall

pip install authlib

バージョンは1.3.2以上じゃないとダメらしい

準備完了！いざ試してみる！

streamlit run main.py
できたー！！
わーーーい！

以上！

おまけ

OpenSSL について

OpenSSL は、暗号化・証明書関連の処理を行うためのコマンドラインツール
今回の openssl rand -hex 32 は、ランダムな秘密キーを生成する
OpenSSL の用途
OpenSSL は以下のような用途で使われます：

HTTPS用の証明書を作成（Let's Encryptなど）
暗号化と復号データの暗号化 (openssl enc コマンド)
ランダムなキーの生成Cookie Secret、APIトークン、パスワード生成
ハッシュ計算openssl dgst -sha256 ファイル名 で SHA256 ハッシュ
RSA 鍵の作成openssl genrsa -out private.key 2048

openssl rand -hex 32

このコマンドの意味：
rand → ランダムなバイト列を生成
-hex 32 → 32バイト分のランダムなデータを16進数（hex）で出力

活用例

  1. Cookieの秘密キー (cookie_secret)

    • OAuth認証で、ブラウザのCookieに保存するセッション情報を暗号化するための秘密鍵

    • ユーザーがログインした後の認証情報を安全に保持するために必要

  2. APIキー・アクセストークンの生成

    • システム内で使う一意な識別子を作成する

  3. パスワードの生成

    • 一時的なパスワードやトークンを発行する

OAuth 2.0 や OIDC（OpenID Connect）について

OIDC（OpenID Connect）は、OAuth 2.0 を拡張してユーザーの「認証」を行うための仕組み

OAuth 2.0 は、「ユーザーが他のサービスに自分のデータへのアクセス権を与える」ための認可（Authorization）の仕組み

OAuth2.0から勉強

OAuth 2.0 の具体例：

  1. GitHub で Google アカウント連携

    • 「Google でログイン」を選ぶと、GitHub が Google に「このユーザーの情報を取得していい？」とリクエストする。

    • Google がユーザーに「GitHub にあなたの情報を渡していいですか？」と確認。

    • 許可すると、GitHub に「この人のメールアドレスは〇〇@gmail.com です」と情報が渡る。

  2. アプリが Google Drive にアクセスする

    • Google Drive に「このアプリがあなたのファイルを読んでもいい？」と許可を求める画面が出る。

    • 許可すると、そのアプリはユーザーのファイルを操作できるようになる。

OAuth 2.0 の特徴

  • ユーザーのデータを「第三者アプリ」に渡せる仕組み

  • 認証ではなく、認可（Authorization）

  • アクセストークン を使って権限を管理する

OIDC（OpenID Connect）とは？

OIDC（OpenID Connect）は、OAuth 2.0 を拡張して、「ユーザーが誰なのか（認証）」も扱えるようにしたもの です。

OAuth 2.0 の問題点

  • 「このユーザーが誰か」 は保証されない（アクセストークンは「データの権限」を持つが、「本人確認」の用途には使えない）

  • OAuth 2.0 では、「このユーザーが本当に本人か？」がわからない

OIDC では「認証（Authentication）」を扱う！

  • OAuth 2.0 には「認可（Authorization）」の仕組みしかない

  • OIDC では「このユーザーは本人だ！」と証明できる

  • IDトークン（JWT）を使ってユーザー情報を取得

一旦整理

  • OAuth 2.0 → 「このアプリが Google Drive のデータを読んでいい？」

  • OIDC → 「このアプリにログインするユーザーは Taro Yamada です！」

OAuth 2.0

目的権限（認可）を与えるユーザーの認証を行う
トークンの種類・・・アクセストークン（Access Token）IDトークン（ID Token）
誰が利用する？・・・アプリがユーザーのデータにアクセスする
ユーザー情報・・・取得できない（権限のみ）

OIDC（OpenID Connect）

トークンの種類・・・IDトークン（ID Token）
誰が利用する？・・・アプリがユーザーの身元を確認する
ユーザー情報・・・sub（ユーザーID）、name（名前） など取得可能

OIDC の仕組み

OIDC の流れ（Google ログインの例）

  1. ユーザーが「Google でログイン」ボタンを押す

  2. アプリが Google に「この人の認証情報をください」とリクエスト

  3. Google のログイン画面が表示され、ユーザーがログイン

  4. Google は ID トークン（JWT）を発行して、アプリに返す

  5. アプリは ID トークンを検証し、ユーザー情報を取得

改めてOIDC とは

OAuth 2.0 の拡張版！
「この人は誰か？」を安全に確認できる 。※OAuth2.0ではできなかった。
Google, Microsoft, Auth0 など、多くのサービスが対応
JWT（JSON Web Token）を使うので、拡張性が高い

server_metadata_url とは？

server_metadata_url は、OIDC（OpenID Connect）の認証サーバーの設定情報を取得するためのURL
このURLを指定すると、Google（または他のOIDCプロバイダー）の 認証エンドポイント や トークン取得URL などを自動的に取得できる

OIDC 認証を行うためには、通常 以下の情報が必要 でとても面倒

  1. 認証エンドポイント（ログインURL）

  2. トークン取得エンドポイント

  3. ユーザー情報取得エンドポイント

  4. 公開鍵情報（JWTの検証用）

  5. サポートされているスコープや認証フロー

  6. その他のOIDC仕様情報

これらの情報を 手動で設定するのは面倒 なので、OIDCでは 「Well-Known URL」 という仕組みを使います。

Google の場合、

https://accounts.google.com/.well-known/openid-configuration

この URL にアクセスすると、すべての情報が JSON で取得できる

いいなと思ったら応援しよう！