1,525 bytes added,
13:01, 11 November 2021 Service Logins allow for easy management of credentials to third-party systems.
== Problem ==
Service Logins are an easy solution to one problem, that occurs almost every time an interface to a third-party system is required: Where to put the credentials? If the interface makes use of Windows Authentication, it's no issue, as <code>WebClient.UseDefaultCredentials</code> will make use of the user the program/service opened. However, in almost all other cases, there's no way around either putting the credentials into the custom code (insecure, as it can be decompiled rather easily...) or creating properties on some MetaClass (that will be plain-text). <code>EncryptedText</code> properties won't work, as there's no way of getting to the plain-text password (that's required for the login to the external system) without using Reflection.
== Features ==
`SERVICE_LOGIN` is the root class of the system, deriving directly from `SYSTEM_OBJECT`. Below that, there are the following derivates:
* TOKEN_AUTH_SERVICE_LOGIN
* TOKEN*
* BASIC_AUTH_SERVICE_LOGIN
* USERNAME
* PASSWORD*
* WINDOWS_AUTH_SERVICE_LOGIN
* USERNAME
* PASSWORD*
* DOMAIN
* OAUTH2_AUTH_SERVICE_LOGIN
* TENANT_ID
* CLIENT_ID
* CLIENT_SECRET*
* CLIENT_CERTIFICATE*
* IDP_URL
* GRANT_TYPE
* SCOPE
The fields with the asterisk (*) are password fields that encrypt the text and store the result in the database. To get the decrypted counterpart, the C# field <SECRETNAME>_DECRYPTED (e.g. TOKEN_DECRYPTED) needs to be accessed.