Decide on initial architecture (Changed)

[miniluz]

Create an initial architecture that can satisfy all requirements.

[miniluz]

The main component to be developed is the "authorization server". It will rely on an "authorization database" containing companies, users and scopes. It will also contain authorization codes and authorization tokens.

Companies will only have a company name identifying them.

Scopes will store a scope token following the format specified in the RFC. They will belong to a specific company and have a maximum span they can be assigned for.

Users will belong to a specific company and have a username and password, stored securely. They can also have roles assigned via a many-to-many relationship.

The authorization server will act as defined in the OAuth 2.0 protocol (only the authorization grant code flow).

• On the client registration endpoint, clients may register. Note that "client" here means the program the user is interacting with, not a client of AstronAuth's services.
• On the authorization endpoint, it will display an HTML page asking the user to log in. After that, it will check that the user has all scopes requested. If they do, it will inform the user of the scopes requested. Finally, if the user consents, it will redirect the user-agent to the URI given, giving an authorization code.
• On the token endpoint, it will give the authorization token token corresponding to the authorization code if it is valid. It will never issue or accept refresh tokens for simplicity.

On top of the standard, it may have a token validation endpoint which verifies the validity of the token. I'll decide if this is necessary later as I read up on what encryption and formats tokens should have.

[miniluz]

The over-all architecture of the system will be the following:

   +---------------+                           +---------------+
   | Authorization |                           | Authorization |
   |   Database    |<------------+             |   Database    |
   |    (Users)    |             |             |   (Clients)   |
   +---------------+         configures        +---------------+
           ^                   users                   ^
           |                     |                     |
   +-------|-------+     +-------|-------+     +-------|-------+
   | Authorization |     | Configuration |     | Authorization |
   |    Server     |     |    Server     |     |    Server     |
   |    (Users)    |     |   (Clients)   |     |   (Clients)   |
   +---------------+     +---------------+     +---------------+
           ^                     ^                     ^
           |                     |                     |
        logs in              accesses            authenticates
         using                   +---------------------+
           |                     |
   +-------|-------+     +-------|-------+
   |               |     |               |
   |     Users     |     |    Clients    |
   |               |     |               |
   +---------------+     +---------------+

The two authentication servers and databases will be identical according to the previous comment.

The user authentication server will authorize user tokens based on the configuration specified in the user authorization database by the clients through the configuration server. For that configuration, they will have to authenticate through the client authentication server which uses the configuration on the client authentication database, controlled by AstronAuth.

Not represented will be two simple registration server, one for clients and one for users, which will allow every user and client to register for demonstration purposes.

[miniluz]

This forces the administrators of AstronAuth to control the client database directly which is not great. However a copy of the configuration server could be launched for that purpose. I may decide on implementing it or not depending on if the effort is warranted.

[miniluz]

The architecture needs to change. See Decide authorization database structure.