Closed miniluz closed 5 months ago
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 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.
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.
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.
The architecture needs to change. See Decide authorization database structure.
Create an initial architecture that can satisfy all requirements.