Oauth Starkiller 645 Nchat

Download as txt, pdf, or txt
Download as txt, pdf, or txt
You are on page 1of 2

# OAuth2

## About
- industry-standard authorisation protocol
- provides authorisation flow for signing-in to web and desktop applications
- in this application I will use OAuth for signing in, generating a session token
that can be used to authenticate requests

## Implementation
- Client: here used to mean the NChat desktop application
- Resource Owner: the user using NChat
- Resource/Authentication server: the combined server responsible for running the
NChat backend and issuing auth tokens
- Access Token: a random hash that must be sent with a HTTP or WebSocket request to
authenticate the user. Will be assigned at sign-in, with a refresh token
- Refresh Token: access tokens are to be valid for a period of up to 2 hours. After
this, they become invalid. An issued refresh token may be used to request a new
access token without requiring the user to sign in agin

The user will open the NChat client, and will be asked to log in. Upon clicking the
login button, they will be redirected to a webpage on their homeserver at
https://[homeserver url]/auth which will allow them to sign-in. They will then be
issued with an access token, a duplicate of which will be stored on their
homeserver along with the requested scopes (detailed below). Then, they will be
redirected back into the NChat client, which will receive the access and optional
refresh token as HTTP response parameters. The access token will be sent along with
every subsequent HTTP and WebSocket logon request, as authentication. If the token
expires, the client will first try using the refresh token to obtain a new access
token transparently. If it cannot, or the token is no longer valid, it will display
this to the user as a 'please login again' message. They will then repeat the flow
to obtain a new access token.

The actual authentication page will be rendered as SSR by Dioxus, the same
framework used for the desktop application. This will enable us to maintain a
consistent layout and styling.
Each access token is mapped to a specific user and shall therefore be used as a way
of uniquely identifying that user. At no point will the user's password be handled
by the client or sent over the network - this ensures security without using
methods such as hashing.
The NChat client will need to register a handler for the nchat:// protocol, which
will be used as a way of passing the authenetication variables. This shall involve
the OS launching the nchat-client binary with args `--auth '<access_token>'` and
optionally `--refresh_token '<refresh_token>'`.

## Scopes
These allow for fine-grained control over what data an application is able to
access. A token granted a high-level scope will also be granted all those below it.

message: Read and write private messages


server: Join or leave servers and channels
admin: Administrate servers on your behalf
channel: Read and write channel messages
profile: Read and write user profile

message: Read and write all messages


message.read: Read messages in all chats
read.server: Read messages only in server chats
read.private: Read messages only in private messages
message.write: Write messages to all chats
write.server: Write messages only in server chats
write.private: Write messages only in private messages
profile: Access and modify all profile data (note that this does not give access to
username/password)
profile.read: Read profile data
profile.write: Modify profile data

You might also like