It's good to see someone talking about OAuth. I feel like OAuth in general is in this kind of awkward place where most devs will almost certainly have to deal with it at some point, but it's complex enough that people will usually just kind of fiddle with it until they can make what they're trying to do work, and then promptly forget all about it until the next time they need it. I know that's definitely how I felt about it until I got a project that kind of forced me to dive deeper into it.
That being said, while you do a good job of explaining the flows, I think it's a bad idea to represent the implicit grant as the "default" OAuth flow or even to really encourage people to use it at all, given that the same OAuth 2.0 Security Best Current Practice document you linked has this to say about it:
In order to avoid these issues, clients SHOULD NOT use the implicit
grant (response type "token") or any other response type issuing
access tokens in the authorization response, such as "token id_token"
and "code token id_token", unless the issued access tokens are
sender-constrained and access token injection in the authorization
response is prevented.
A sender-constrained access token scopes the applicability of an
access token to a certain sender. This sender is obliged to
demonstrate knowledge of a certain secret as prerequisite for the
acceptance of that token at the recipient (e.g., a resource server).
Clients SHOULD instead use the response type "code" (aka
authorization code grant type) as specified in Section 3.1.1 or any
other response type that causes the authorization server to issue
access tokens in the token response. This allows the authorization
server to detect replay attempts and generally reduces the attack
surface since access tokens are not exposed in URLs. It also allows
the authorization server to sender-constrain the issued tokens.
Yeah, using PKCE definitely helps, but people still really shouldn't be using the implicit grant unless they absolutely need to. The Authorization Code grant is both more secure by default and significantly more common in the wild (in my experience, at least), and there's no reason you can't use it if you're building a typical web app.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's good to see someone talking about OAuth. I feel like OAuth in general is in this kind of awkward place where most devs will almost certainly have to deal with it at some point, but it's complex enough that people will usually just kind of fiddle with it until they can make what they're trying to do work, and then promptly forget all about it until the next time they need it. I know that's definitely how I felt about it until I got a project that kind of forced me to dive deeper into it.
That being said, while you do a good job of explaining the flows, I think it's a bad idea to represent the implicit grant as the "default" OAuth flow or even to really encourage people to use it at all, given that the same OAuth 2.0 Security Best Current Practice document you linked has this to say about it:
Yeah, using PKCE definitely helps, but people still really shouldn't be using the implicit grant unless they absolutely need to. The Authorization Code grant is both more secure by default and significantly more common in the wild (in my experience, at least), and there's no reason you can't use it if you're building a typical web app.