Added Authentication API

[SpongeManiac]

Adds the ability to perform authentication by purely using the API, JSON, and Cookie Headers.

An updated and squashed version of my previous pull request.
I am still learning pull requests, so any advice and pointers would be helpful. Thank you!

Added authentication.cr
Updated routes.cr
Updated captcha.cr
Updated tokens.cr

[unixfox]

You technically don't have to create a new PR for squashing commits :) (next time it would be great to do it under the same PR).

[SpongeManiac]

@unixfox I could not squash my commits in that branch. I tried several different ways, but to no avail. I'm not an expert at Github, so the easiest solution I could find was to cherry pick my commits without a merge, then squash, then merge. For whatever reason, Github would not allow me to squash these commits on that branch. My apologies if I'm doing something the round about way, I have never done a pull request, or had a pull request give me these errors. If there is a way to open the same PR but for a different branch, I would love to know.

[SamantazFox]

What I can recommend for the next time you need to squash commits:

1. backup your repo (in case you make a mistake! That saved me countless times)
2. rebase your changes interactively: git rebase -i master
3. When you are happy with the code, push changes git push --force-with-lease your_fork your-branch

[SamantazFox]

I have a few questions regarding this PR:

• Why is this feature needed for? Could you provide some use cases?
• Why do you want to automate registration using the API?
• Why do you need to log-in using cookies? Why can't you use Authentication: Bearer <token>?
• Have you looked at [RFC] Authentication and Authorization API #473 ?

[SpongeManiac]

@SamantazFox I've looked through the API on the official website. Not only is it out of date, it is poorly documented. I was having troubles using token authentication because of the following issues:

1. There is no way to register, login, and create tokens through purely JSON
2. When using bearer tokens, you must url encode a JSON object, which is unnecessary and is frankly inefficient when you could just use JSON
3. The path /authorize_token and the path /api/v1/auth/tokens/register requires you to have authorized somehow already. This would mean I would have to use cookies, then generate a token. Why use the token if I could just use the cookie sid? Again, this route for some reason uses www encoded json, which seems inefficient considering you could just use JSON.
4. I am coding a cross-platform application to use the invidious API. To make API requests from one domain to another, CORS headers must be added. Authentication headers are not allowed in CORS requests, meaning I cannot use bearer token.

These routes I implemented are the easiest way to accomplish my task; a collection of endpoints that operate on purely JSON to perform registration and authentication. If you would like, I could create a separate PR to attempt to alter existing API to fit my needs while still functioning identically. The only reason I did not do this is because it would change how the Front End sends requests, and how the back end processes the requests.

[SamantazFox]

yes, I know about the bad state of our API docs. Sorry for that :/

Not being able to register through the API is normal. I'm not aware of any website/service that allows to do so (they all require the user to manually create an account first). As for the login, it's not required once you have an API token. An SID cookie is simply an API token with a wildcard scope (:*). If you can't use the Authentication header, then you can still pass that token as the SID cookie.

But I'm wondering why you couldn't use the Authentication header. Its use is limited by CORS in the same way as the Cookie header. So if you can't use one, you can't use the other (See MDN page for reference).

As far as my knowledge goes, the best option is to use your own invidious instance (so that you can control CORS response headers) or use some middleware to do the request, rather than handling that on the client side.

As for the /authorize_token route, like the /login one, you're supposed to redirect your user there, where they can grant access to your app, or not. PR #3556 has streamlined the authentication/authorization flow: you can redirect your user to /authorize_token, invidious will ask them to login, grant access, and redirect back to your site all at once.

I admit that the token management UI is terrible, and would need a refresh.

[github-actions]

This pull request has been automatically marked as stale and will be closed in 30 days because it has not had recent activity and is much likely abandoned or outdated. If you think this pull request is still relevant and applicable, you just have to post a comment and it will be unmarked.