Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

アプリケーションを廃止 #5656

Closed
tamaina opened this issue Dec 21, 2019 · 61 comments
Closed

アプリケーションを廃止 #5656

tamaina opened this issue Dec 21, 2019 · 61 comments
Labels
🧩API Interface between server and client 💬Discussion Being discussed or needs discussion ✨Feature This adds/improves/enhances a feature packages/backend Server side specific issue/PR
Projects
v12

Comments

@tamaina
Copy link
Member

tamaina commented Dec 21, 2019 •
edited

Summary

https://misskey.io/notes/7zfchyqpdt
https://misskey.io/notes/7zfczb7wh0

app/createでログインなしに誰もが大量にアプリケーションを作成できるようになった今、APIキー(i)の生成手順としてのアプリケーションのというのがあまり意味を成しておらず形骸化しており、アプリケーションを廃止してもいいのではないでしょうか。

新手順（案）

DBやマイグレーションのことはあまり考えていませんがそんなに難しくないはず

1. auth/session/create に今までapp/createに渡していたようなデータを渡す

{
// アプリの名前（今までどおりviaは表示したいので）
  name: "test",
// アプリの説明
  description: "my test application",
// アプリのパーミッション
  permission: ["write:notes"],
// コールバック
  callbackUrl: "https://my.app.tld/cb/misskey"
}

token（例: 798b9f6e-248d-43a7-a919-fabc664027f1）とurlが返ってくるのは現在と同様だが、新たにid（アクセスID(?), aid 例: 81jci5eqr0）が加わる。これをappSecretの代わりとする。

2. accessTokenを問い合わせる

ユーザーの認証が終わって{ callbackUrl }?token=798b...にアクセスされたらauth/session/userkeyにappIdとtokenを送信

{
  id: "81jci5eqr0",
  token: "798b9f6e-248d-43a7-a919-fabc664027f1"
}

accessTokenが返ってくるのは今までと同様。

3. APIキー(i)の生成

appSecretがidに変わっただけ

sha256(accessToken + id)
@tamaina tamaina added the ✨Feature This adds/improves/enhances a feature label Dec 21, 2019
@rinsuki
Copy link
Contributor

rinsuki commented Dec 21, 2019 •
edited

その都度生成がほぼ必須なクライアントアプリならそれでもいいかもしれないが、サーバー側で一回生成したアプリを使い回せるサードパーティーWebサービスへのログインだとアクセストークンが毎回生成されるのはだるそうな気がする

@syuilo syuilo added this to Maybe in v12 Jan 12, 2020
@syuilo
Copy link
Member

syuilo commented Jan 21, 2020 •
edited

ユーザーが自由にアクセストークン的なものを発行できるようにして、それをアプリに入力させる方法はどうでしょう
アプリは入力されたアクセストークンを使ってAPIを利用できる

@rinsuki
Copy link
Contributor

rinsuki commented Jan 21, 2020

面倒くさそう

@rinsuki
Copy link
Contributor

rinsuki commented Jan 21, 2020

(それはそれとしてその機能は書き捨てスクリプトとかに便利そうなので別で欲しい)

@tamaina
Copy link
Member Author

tamaina commented Jan 21, 2020 •
edited

アクセストークンが毎回生成される

今もそうなのでは...?（毎回というか一回の要求に対してだけど）

ユーザーが自由にアクセストークン的なものを発行

権限とかはアプリ側で指定する必要がありますし、そこまで思い切るのは厳しいかなと
ユーザーにしてみればボタンのクリックで完結したほうが簡単だし

@syuilo
Copy link
Member

syuilo commented Jan 21, 2020 •
edited

ユーザーが自由にアクセストークン的なものを発行する方式でも、実装の仕方によっては今まで通りボタンのクリックのみで完結させることはできそう: 例えば

  1. アプリがMisskeyの指定の認証ページ(トークン発行要求ページ)を開かせる
  2. ユーザーがOKボタンみたいなのを押す
  3. トークンが発行されて、Misskeyサーバーから何らかの方法でイベントが伝えられアプリはそれを入手できる

とかどうかな

@syuilo
Copy link
Member

syuilo commented Jan 21, 2020

アクセストークンを保存しておけば、同じアプリ/Webサービスのアクセストークンが何個も生成されるということは無くなると思う

@tamaina
Copy link
Member Author

tamaina commented Jan 21, 2020

トークン発行ページがクエリ文字列とかを受け付けて、必要なら名前とかを変えてOKボタン押すだけみたいな感じ？

@syuilo
Copy link
Member

syuilo commented Jan 21, 2020

そうそう
権限もユーザーが必要なら編集することができるとか

@tamaina
Copy link
Member Author

tamaina commented Jan 21, 2020 •
edited

支障はなさそうだけど、事情に詳しくないユーザーが変なふうに権限やコールバックURLを編集し、アプリ作者に動かないと文句を言うというのが想像できるので、最初は編集不可にしておいて変更するときは変更ボタンを押してからできるようにするみたいな画面にするのが望ましそう

@syuilo syuilo added packages/backend Server side specific issue/PR 💬Discussion Being discussed or needs discussion 🧩API Interface between server and client labels Jan 21, 2020
@rinsuki
Copy link
Contributor

rinsuki commented Jan 21, 2020

アクセストークンを保存しておけば、同じアプリ/Webサービスのアクセストークンが何個も生成されるということは無くなると思う

アクセストークンを保存とは…?

@syuilo
Copy link
Member

syuilo commented Jan 21, 2020

Webサービスが自分のデータベースに保存するなど

@rinsuki
Copy link
Contributor

rinsuki commented Jan 21, 2020

ログインの時点では誰だかわからないのでアクセストークンわからなさそう

@syuilo
Copy link
Member

syuilo commented Jan 21, 2020

ふーむ

@tamaina
Copy link
Member Author

tamaina commented Jan 21, 2020 •
edited

あー、Misskeyアカウント自体をアプリのログイン時の認証としている場合はアクセストークンを使い捨てることになるってことか

@syuilo
Copy link
Member

syuilo commented Jan 21, 2020

ログインの時点で誰だかわかるシステムを新たに作るとか？
そのシステムではあくまでも誰だかわかるだけで、アプリの認証とかはしない
認証はさっき言ったトークン発行方式を使うとか

@rinsuki
Copy link
Contributor

rinsuki commented Jan 21, 2020

個人的にはWebサービス用にアプリを残してスタンドアローンアプリ用の仕組みを別途作るのがよい気がする

@syuilo
Copy link
Member

syuilo commented Jan 21, 2020

なるほど
まあ既存のアプリ方式は互換性のために残すことは確実なんですけど、できればWebサービスでもスタンドアロンでも同じ(新しい)認証方式を使えるようにしたいというのもあります

@rinsuki
Copy link
Contributor

rinsuki commented Jan 24, 2020

いろいろ考えてもやはりアプリ形式が板な気がするし、アプリ形式を「アプリ」じゃなくて「使い回すと前回と同じアクセストークンがもらえる認証リクエスト」と思うといいのかもしれない

@syuilo
Copy link
Member

syuilo commented Mar 20, 2020 •
edited

UI上(開発者センター)でアプリ作成できるようにする必要ってなさそうかな
分散型になった今、特定のインスタンスだけで使えるサードパーティアプリ作りたくなるケースって無さそうだし

@syuilo
Copy link
Member

syuilo commented Mar 21, 2020

互換性は残しつつも、「アプリ」という名称は変えた方が良さそうだなぁ

@syuilo
Copy link
Member

syuilo commented Mar 26, 2020

サードパーティーWebサービスへのログインだとアクセストークンが毎回生成されるのはだるそうな気がする

クライアントアプリでアクセストークンが毎回生成される時点で、Webサービスだけ特別扱いして使いまわせるようにする必要も特にないのかなと思えてきた

@rinsuki
Copy link
Contributor

rinsuki commented Mar 26, 2020

でも同じWebサイトにログインするたびにアプリ連携のところにWebサイト増えてったら嫌じゃない?

@syuilo
Copy link
Member

syuilo commented Mar 26, 2020

そもそもなんでクライアントアプリだとアクセストークン毎回生成しないといけないんだっけ

@rinsuki
Copy link
Contributor

rinsuki commented Mar 26, 2020

端末間でアプリのClientID/Secretを共有する方法がないから

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020 •
edited

全然知らないWebサービスに、許可なく自分のアカウントIDだけでも分かってしまうのってプライバシー的に何か問題あるかな？

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

問題あるか

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

Webサービスで使いまわせない問題はいったん置いておいて、こんな方法考えたけどどうだろう
image

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020

uuid重複したらどうなるのこれ

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

既に使われたUUIDはサーバーサイドで弾くことを予定

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020

UUID自己申告よりサーバーにpermissionsとcallback送ってUUID返してそのUUIDでページに飛ばすみたいな仕組みのほうが便利そう (サーバーの対応/非対応判定もできるし)

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020

あとcallback URLに直接tokenが飛んでくるの各所のアクセスログに残るのであまりよくなさそう

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

UUID自己申告よりサーバーにpermissionsとcallback送ってUUID返してそのUUIDでページに飛ばすみたいな仕組みのほうが便利そう

クライアントの実装の手間がひと手間増えないかな

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

あとcallback URLに直接tokenが飛んでくるの各所のアクセスログに残るのであまりよくなさそう

ほう この点は変えても良いかもしれない

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

tokenの代わりにUUIDを付けてリダイレクト？と思ったけどそれ実質token付けてるのと同じか

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

アクセスログについては気にしなくてもよい気がする

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020 •
edited

クライアントの実装の手間がひと手間増えないかな

MFMに比べたら5億倍マシ ページに飛ばす前に一回APIを叩かない方式だと、泥臭いバージョン取得&判定をしないとサーバー側で非対応インスタンスということに気づけないのと、自己申告だとUUID被った時にユーザーにエラー画面出るだけになっちゃうのUX低そう、というのを考えると (UUID自体の被る率はそんな高くないだろうけど、使ってるのが質のよくない乱数源とかだと被りやすくなるはずなので、なくはなさそう) 一回セッション作成APIみたいなのを叩かせたほうがよさそう

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020

あとこれ名前とか指定できないけどただの付け忘れ? どこでどの端末で認証したかだけじゃどのサービスのトークンかわからなくなりそう

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

あとこれ名前とか指定できない

自己申告だからいくらでも偽装とか出来そうだし敢えて入れなかった

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020

でも後から何が何だかわからなくならない?

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

何が何だかわかる必要ってあるかな

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020

このアプリやっぱ気に食わないな〜権限取り上げてえ〜って時

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

とりあえず名前(とかアイコンとか)設定可能にするか

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020 •
edited

アクセスログについては気にしなくてもよい気がする

  1. トークンがそのまま残ると、サーバー側に残ったログから抽出しやすい (ログが流出してしまった時のことを考えると…)
  2. トークンをそのまま送ると、悪意のあるなしはさておきURLを外部に送るプロキシ/ブラウザ拡張機能とかに取られやすそう

ので、UUIDを返して、UUIDから取れるのは一回限り、みたいにしたほうがまだセキュアそう (本当はUUIDを返すついでにclient_secretも返してそれが必要になるほうがいいと思うけど、それもう現行のアプリケーションじゃん)

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

取れるのは一回限り

なるほど

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020

というかもう現行のアプリケーションの名前変えるだけでいいのでは?実は

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020 •
edited

でも名前変えるにしろうまい名前思いつかないし、別に現状でいいのではって思う (/dev/でアプリ作れなくていいのは賛同するけど、v12で/dev/ごと消えたっぽいし)

どうせ現行のアプリ仕様だろうがトークン毎回発行にしようが結局ユーザーにトークン一覧を出してrevokeさせる以上は大量に(アプリ名)っていうトークンが並ぶのは変わらないし…

(それはそれとして、強いて言うならアプリorセッション作るときに端末名とかの認証したユーザーだけに見える付加情報を入れられるようにするといいかもしれない)

@syuilo
Copy link
Member

syuilo commented Mar 27, 2020

大量に(アプリ名)っていうトークンが並ぶのは変わらないし

アプリ作成の手間だったり、シークレットキーという概念だったり、セッション作成API叩く手間だったり、sha256する手間だったりを削れたらいいなというのもモチベーションのひとつではある

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020

ふ〜む

@rinsuki
Copy link
Contributor

rinsuki commented Mar 27, 2020 •
edited

シークレットキーはどうしようもなさそう
sha256は破壊的変更なしでなくす変更入れられそう

@syuilo
Copy link
Member

syuilo commented Mar 28, 2020

あとこの方法だと権限をユーザーが設定できるというのがある
「このアプリはxxとyyの権限を要求してるけど不安だからxxだけにしとこう」とか

@syuilo
Copy link
Member

syuilo commented Mar 28, 2020

やった

@syuilo syuilo closed this as completed Mar 28, 2020
@mei23 mei23 mentioned this issue Mar 29, 2020
Closed
@syuilo syuilo moved this from Maybe to Done in v12 May 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
🧩API Interface between server and client 💬Discussion Being discussed or needs discussion ✨Feature This adds/improves/enhances a feature packages/backend Server side specific issue/PR
Projects
No open projects
v12
  
Done
Milestone
No milestone
Development

No branches or pull requests
3 participants
@syuilo @rinsuki @tamaina