Add sign-in request for authentication token retrieval

[farost]

Release notes: usage and product changes

A new mechanism of authentication tokens has been introduced to replace the old way of sending usernames and passwords through the network with every request.

Instead, all user credentials (currently, it's usernames and passwords) are sent only:

• as a part of connection_open request for authentication and authorization, with a temporary token returned;
• as a part of sign_in request for #s within an established connection (to change the user or to get a new authentication token).
  Then, all further requests are expected to be authenticated only by temporary, less sensitive tokens.

The approach is extensible to other credential types that can be introduced in the future.

Implementation

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• This change is trivial and does not require a code or architecture review.

Code

• Packages, classes, and methods have a single domain of responsibility.
• Packages, classes, and methods are grouped into cohesive and consistent domain model.
• The code is canonical and the minimum required to achieve the goal.
• Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• The code is algorithmically efficient and scalable for the whole application.

Architecture

• Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• Any required build and release automations are updated and/or implemented.
• Any new components follows a consistent style with respect to the pre-existing codebase.
• The architecture intuitively reflects the application domain, and is easy to understand.
• The architecture has a well-defined hierarchy of encapsulated components.
• The architecture is extensible and scalable.

[farost]

Sometimes it's called UserPassword in APIs, maybe it's better to signal that it's not just a password.

[farost]

Idk how to name it, please share ideas.

[farost]

Doesn't feel like a part of the User API, so I declared a new package. In the future, there can be RefreshToken or whatever, so it won't be totally empty, and the scope is clearer.

[flyingsilverfin]

Maybe this is GetToken? Because you're sending username/pass -> token? Not specifically to do with signing in right here?

[flyingsilverfin]

Or just Token, then you have Req and Res subtypes!

[farost]

It's quite a #: you # with credentials, and you get your access token for further authentication/authorization. Just like in REST, you # into a website, and then your token is cached in your cookies, so it is used for authentication/authorization for further requests. I don't mind renaming it to GetToken here though, I'd still name it a "#" in HTTP, so I decided to add some symmetry.

[farost]

Definitely not Token as we can Refresh it in the future.

[flyingsilverfin]

Well Token.Refresh makes sense too right?

[farost]

Token.Req, Token.Res, Token.Refresh.Req, Token.Refresh.Res? Is it a common approach?

[flyingsilverfin]

what does refresh do differently from the regular one?
otherwise we can have Token.Create.Req/Res and Token.Refresh.Req/Res

[farost]

Oh, okay, this is a good option. I thought you wanted Token.Req and Token.Res, and then append Token.Refresh to it.
But I'd still want it to be a part of Authentication, because it's the general scope, and we could have some other entities of authentication in the future.

[flyingsilverfin]

ok, that works for me :)