A role is a named group of OAuth identities. You use roles to authorise who can reach an app and who can use a token. Instead of granting access to individuals one by one, you put people into a role and grant the role.
What a role is
A role collects the OAuth identities (the logins) of the people who should have a particular level of access. When someone signs in, OINO.cloud looks at which roles their identity belongs to and lets them through wherever those roles are required.
Roles are the link between who a user is and what they may touch:
- Tokens: a token can require one or more roles. Only a signed-in user whose identity is in one of those roles may read or write the data behind that token.
- Apps: an app's login is gated by the union of the roles required by its pages' tokens. Being in one of those roles is what lets a user open the app.
You can restrict a role down to specific individuals by email address, so a role can be as broad as a whole team or as narrow as a single person.
Public vs. protected
Tokens start out public — they have no roles, so anyone with the URL can use them. The moment you attach a role to a token, it becomes protected: users must sign in and be in that role to use it. This one distinction is what makes a page public or private and what puts a login in front of an app.
Single sign-on (SSO)
If SSO is enabled for your organisation, roles can additionally come from your identity provider (IdP). Group memberships defined in the IdP are mapped into OINO.cloud roles, so access follows your existing directory automatically — on top of any identities you assign to a role by hand.
Working with roles
- Create a role and give it a clear name (e.g.
editorsorfinance). - Add the OAuth identities — or specific email addresses — that belong in it. With SSO, matching IdP groups fill the role automatically.
- Require the role on the tokens that guard sensitive data.
- Users in the role can now sign in to the apps and use the tokens that require it.
Tip: keep roles small and purpose-built — one per level of access — rather than reusing a broad role everywhere. This mirrors the token guidance in the Security guide and keeps access easy to reason about.
