remove MiAuth

Johann150 commented

2022-11-06 16:59:03 +00:00

Owner

With the work towards adding OAuth, keeping MiAuth would basically undermine the security that OAuth is supposed to provide. It is by my consideration also generally unsafe. In Oauth terminology it is a implicit grant with unregistered clients which are two things that are not recommended by the security best practices and would require more security consideration which I highly doubt has taken place.

This includes at least the following tasks:

removing 2 client pages
removing 2 endpoints (one of them is directly attached in server/api/index.ts for some reason)
cleaning up now unused fields on AccessToken
removing the features.miauth attribute from the meta endpoint

With the work towards adding OAuth, keeping MiAuth would basically undermine the security that OAuth is supposed to provide. It is by my consideration also generally unsafe. In Oauth terminology it is a implicit grant with unregistered clients which are two things that are not recommended by the security best practices and would require more security consideration which I highly doubt has taken place. This includes at least the following tasks: - removing 2 client pages - removing 2 endpoints (one of them is directly attached in `server/api/index.ts` for some reason) - cleaning up now unused fields on `AccessToken` - removing the `features.miauth` attribute from the meta endpoint

👍 1

Johann150 added this to the (deleted) project 2022-11-06 16:59:03 +00:00

Johann150 commented

2022-11-07 21:49:18 +00:00

Author

Owner

Interesting question that I didn't realize yet: There is this thing in settings where you can manually generate a token. That is built on MiAuth.

The question being: Do we want to keep that kind of thing or will we require everyone to use OAuth for that? I guess the use case for something like this would be for building bots that will only require a token once.

That of course doesn't mean we have to keep MiAuth around, can just as well implement that on top of the OAuth mechanism with a "internal" app that redirects back to the UI.

Interesting question that I didn't realize yet: There is this thing in settings where you can manually generate a token. That is built on MiAuth. The question being: Do we want to keep that kind of thing or will we require everyone to use OAuth for that? I guess the use case for something like this would be for building bots that will only require a token once. That of course doesn't mean we have to keep MiAuth around, can just as well implement that on top of the OAuth mechanism with a "internal" app that redirects back to the UI.

toast commented

2022-12-03 12:19:35 +00:00

Owner

The question being: Do we want to keep that kind of thing

For sure yes.

That of course doesn't mean we have to keep MiAuth around, can just as well implement that on top of the OAuth mechanism with a "internal" app that redirects back to the UI.

Yeah, that sounds good to me.

> The question being: Do we want to keep that kind of thing For sure yes. > That of course doesn't mean we have to keep MiAuth around, can just as well implement that on top of the OAuth mechanism with a "internal" app that redirects back to the UI. Yeah, that sounds good to me.

Johann150 added the

fix

label 2022-12-23 10:21:42 +00:00

Johann150 removed this from the (deleted) project 2022-12-23 10:21:44 +00:00

Johann150 commented

2023-02-28 17:55:47 +00:00

Author

Owner

In the process of trying to debug #351 I noticed that Milktea - which seems to be used by quite a few Foundkey users - does not use Miauth but instead uses App Auth. I don't know if we can take that to be an indication of anything, but if yes then it is a good one.

In the process of trying to debug #351 I noticed that Milktea - which seems to be used by quite a few Foundkey users - does *not* use Miauth but instead uses App Auth. I don't know if we can take that to be an indication of anything, but if yes then it is a good one.

remove MiAuth #225