implement bearer token authentication #15

Manually merged
Johann150 merged 5 commits from bearer-authentication into main 2022-07-20 13:11:43 +00:00
Owner

Bearer token authentication is implemented on the back end. This should eventually help with problems brought up in #14 (but the client also needs to be adjusted).

Since we already basically used bearer tokens this is not really tricky, it just has to be put into/taken from the right fields & formats for OAuth 2.0.

Bearer token authentication is implemented on the back end. This should eventually help with problems brought up in #14 (but the client also needs to be adjusted). Since we already basically used bearer tokens this is not really tricky, it just has to be put into/taken from the right fields & formats for OAuth 2.0.
Johann150 added 4 commits 2022-07-18 21:33:12 +00:00
Johann150 added this to the (deleted) project 2022-07-18 21:33:24 +00:00
Johann150 added a new dependency 2022-07-18 21:34:41 +00:00
Johann150 added 1 commit 2022-07-18 22:50:01 +00:00
First-time contributor

Does this break compatibility with the Misskey API?

As far as I understand it, this is just a different keyword in the JSON to mark the token, so I can just pass it in two different flavours to be compatible with Misskey and Foundkey?

{
"i": "token",
"Bearer": "token"
}
Does this break compatibility with the Misskey API? As far as I understand it, this is just a different keyword in the JSON to mark the token, so I can just pass it in two different flavours to be compatible with Misskey and Foundkey? ``` { "i": "token", "Bearer": "token" } ```
Author
Owner

This is not a breaking change. (yet?)

You are not quite right, the alternative way to pass in the token is via the HTTP Header Authorization in the format Bearer <token> (where <token> is what you put in i). This is a standardized mechanism from OAuth 2.0 called Bearer Token Authentication.

Note that passing in the token both ways is forbidden by the OAuth specification and will cause an error.

This is not a breaking change. (yet?) You are not quite right, the alternative way to pass in the token is via the HTTP Header `Authorization` in the format `Bearer <token>` (where `<token>` is what you put in `i`). This is a standardized mechanism from OAuth 2.0 called Bearer Token Authentication. Note that passing in the token both ways is forbidden by the OAuth specification and will cause an error.
Author
Owner

Also made a pull request to add this to Misskey: https://github.com/misskey-dev/misskey/pull/9021

Also made a pull request to add this to Misskey: https://github.com/misskey-dev/misskey/pull/9021
toast approved these changes 2022-07-20 11:09:50 +00:00
Owner

LGTM - has this been tested? If so the merge button should be pressed imo ^^

LGTM - has this been tested? If so the merge button should be pressed imo ^^
Johann150 manually merged commit f3e196528f into main 2022-07-20 13:11:43 +00:00
Author
Owner

Is running on my instance and didn't notice issues.

Is running on my instance and didn't notice issues.
Johann150 deleted branch bearer-authentication 2022-07-20 13:12:16 +00:00
norm referenced this issue from a commit 2022-08-28 14:46:46 +00:00
Johann150 added the
fix
label 2022-12-23 10:20:17 +00:00
Johann150 removed this from the (deleted) project 2022-12-23 10:20:20 +00:00
Sign in to join this conversation.
No reviewers
No Label
feature
fix
upkeep
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Blocks
Reference: FoundKeyGang/FoundKey#15
No description provided.