Difference between revisions of "Standards:GMCP Authentication"
(Externalise OAuth and support accounts) |
(may -> shall notify of no credentials available) |
||
(7 intermediate revisions by the same user not shown) | |||
Line 9: | Line 9: | ||
=== Design === | === Design === | ||
− | The extension introduces a new namespace called <code> | + | The extension introduces a new namespace called <code>Char.Login</code> with the following commands: |
==== Server-side ==== | ==== Server-side ==== | ||
− | ===== | + | ===== Char.Login.Default===== |
− | Sent in response to <code>Client.Supports.Set</code>, it informs the client of the supported authentication methods: | + | Sent in response to <code>Client.Supports.Set</code>, or as soon as telnet negotiation completes, it informs the client of the supported authentication methods: |
*<code>type</code> (array of strings, required): indicates the supported method(s), which is one or more of: | *<code>type</code> (array of strings, required): indicates the supported method(s), which is one or more of: | ||
**<code>password-credentials</code>: traditional username/password login. | **<code>password-credentials</code>: traditional username/password login. | ||
Line 23: | Line 23: | ||
Since multiple flows can be supported by a server, the <code>type</code> array shall be ordered in the descending order of preference by the server. For example, if the server supports only the credentials flow: | Since multiple flows can be supported by a server, the <code>type</code> array shall be ordered in the descending order of preference by the server. For example, if the server supports only the credentials flow: | ||
− | + | Char.Login.Default {"type": ["password-credentials"]} | |
If the server supports both OAuth and credentials and prefers OAuth: | If the server supports both OAuth and credentials and prefers OAuth: | ||
− | + | Char.Login.Default {"type": ["oauth", "password-credentials"], "location": "<nowiki>https://example.com/.well-known/openid-configuration</nowiki>" } | |
− | ===== | + | ===== Char.Login.Result ===== |
− | Sent in response to <code> | + | Sent in response to <code>Char.Login.Credentials</code>, it informs the client of the success or failure of the credentials-based login. |
− | * <code>success</code>: (boolean, required) Indicates whether the authentication attempt was successful. | + | * <code>success</code>: (boolean, required) Indicates whether the authentication attempt was successful. Can be a string value for compatibility with aged MUD drivers. |
* <code>message</code>: (string, required if <code>success</code> is false) required string if the login wasn't successful: a human-readable message explaining the result, such as "Invalid credentials" or "Character not found". | * <code>message</code>: (string, required if <code>success</code> is false) required string if the login wasn't successful: a human-readable message explaining the result, such as "Invalid credentials" or "Character not found". | ||
==== Client-side ==== | ==== Client-side ==== | ||
− | ===== | + | ===== Char.Login.Credentials ===== |
− | After receiving <code> | + | After receiving <code>Char.Login.Default</code> with <code>type</code> as <code>password-credentials</code>, the client sends the character name and password for traditional login. |
− | * <code>account</code> (string, required): character name or the player account name. For games that implement both player and character names, the character name | + | * <code>account</code> (string, required): character name or the player account name. For games that implement both player and character names, the character name can be included after a colon (:), for example <code>myaccount:mycharacter</code>. |
* <code>password</code> (string, required): character password. Servers are encouraged to implement [[Manual:Supported Protocols#Secure connection .28TLS.29|TLS over telnet]] to allow secure transmission of passwords. | * <code>password</code> (string, required): character password. Servers are encouraged to implement [[Manual:Supported Protocols#Secure connection .28TLS.29|TLS over telnet]] to allow secure transmission of passwords. | ||
+ | In case the client does not know both the character name and password, it shall notify the server of this by sending an empty response. This can be used a response to any authentication method: | ||
+ | |||
+ | <code>Char.Login.Credentials {}</code> | ||
+ | |||
'''Example Flow (Password Credentials):''' | '''Example Flow (Password Credentials):''' | ||
− | # Client connects and sends: <code>Core.Supports.Set [" | + | # Client connects and sends: <code>Core.Supports.Set ["Char.Login 1", ...]</code> |
− | # Server responds with: <code> | + | # Server responds with: <code>Char.Login.Default {"type": ["password-credentials"]}</code> |
− | # Client sends: <code> | + | # Client sends: <code>Char.Login.Credentials {"account": "username", "password": "password"}</code> |
# Server validates credentials and performs login. | # Server validates credentials and performs login. | ||
− | [[File:GMCP | + | [[File:GMCP authentication flow.png|alt=|none|thumb|780x780px|Example password flow ([https://gist.github.com/vadi2/6fcc05500823122143a5d45c43915ff0 source])]] |
Latest revision as of 09:32, 8 August 2024
GMCP Extension for MUD Client Authentication
This document defines a new GMCP extension to enable MUD clients to send credentials and perform authentication using GMCP messages instead of in-band login commands. It also includes optional support for OAuth authorization flows.
Rationale
Different MUDs have diverse login command formats, making it challenging for MUD clients to handle login consistently. This extension provides a standardized way to exchange authentication information through GMCP, simplifying client development and improving compatibility. Additionally, the extension supports OAuth authorization flows, allowing clients to leverage external identity providers for login.
Design
The extension introduces a new namespace called Char.Login
with the following commands:
Server-side
Char.Login.Default
Sent in response to Client.Supports.Set
, or as soon as telnet negotiation completes, it informs the client of the supported authentication methods:
type
(array of strings, required): indicates the supported method(s), which is one or more of:password-credentials
: traditional username/password login.oauth
: OAuth-based login.
location
(string, required iftype
isoauth
): openid-configuration location. See https://openid.net/specs/openid-connect-discovery-1_0.html
Since multiple flows can be supported by a server, the type
array shall be ordered in the descending order of preference by the server. For example, if the server supports only the credentials flow:
Char.Login.Default {"type": ["password-credentials"]}
If the server supports both OAuth and credentials and prefers OAuth:
Char.Login.Default {"type": ["oauth", "password-credentials"], "location": "https://example.com/.well-known/openid-configuration" }
Char.Login.Result
Sent in response to Char.Login.Credentials
, it informs the client of the success or failure of the credentials-based login.
success
: (boolean, required) Indicates whether the authentication attempt was successful. Can be a string value for compatibility with aged MUD drivers.message
: (string, required ifsuccess
is false) required string if the login wasn't successful: a human-readable message explaining the result, such as "Invalid credentials" or "Character not found".
Client-side
Char.Login.Credentials
After receiving Char.Login.Default
with type
as password-credentials
, the client sends the character name and password for traditional login.
account
(string, required): character name or the player account name. For games that implement both player and character names, the character name can be included after a colon (:), for examplemyaccount:mycharacter
.password
(string, required): character password. Servers are encouraged to implement TLS over telnet to allow secure transmission of passwords.
In case the client does not know both the character name and password, it shall notify the server of this by sending an empty response. This can be used a response to any authentication method:
Char.Login.Credentials {}
Example Flow (Password Credentials):
- Client connects and sends:
Core.Supports.Set ["Char.Login 1", ...]
- Server responds with:
Char.Login.Default {"type": ["password-credentials"]}
- Client sends:
Char.Login.Credentials {"account": "username", "password": "password"}
- Server validates credentials and performs login.
OAuth Flows
Specific details for the OAuth flow will be detailed once it is worked out with the community.
Implementation Considerations
- This extension should be implemented according to the GMCP protocol specifications.
- Messages should be well-formatted JSON objects.
- Servers should validate incoming authentication information securely.
- Clients should handle potential errors and server responses gracefully.
Conclusion
This GMCP extension provides a standardized and flexible approach to MUD client authentication, improving compatibility and enabling support for OAuth authorization flows. By adopting this extension, MUD developers and client developers can simplify login processes and enhance user experience.
Note: This is a draft proposal, and further community input and refinement may be necessary before finalizing the specification. Additionally, the specific details of OAuth flow support require input from the community to be defined.