Skip to content

Home

Jump to bottom
Mark Overmeer edited this page Oct 28, 2026 · 26 revisions

Open Console connection provider

Another word to describe this feature is "log-in service".

In the Open Console philosophy, a right to access data is not always (and often not only) based on personal identities. For instance, when a Service wants to show information about a website, it may only require a proof of website ownership without the need to know personal data of the visitor.

Compared to OpenID, there are many additional ways to establish access rights. Besides, it uses mainly RFCs and IANA based field specifications, because they are stricter defined. OpenID compatible output may be provided in the future.

Terms

  • ID, identifier assigned the Open Console data object. IDs are cryptographically random, and max 128 printable ASCII characters long, a Bearer token (RFC6750). They show the application which created them, and the class of the object. We MAY implement token introspection (RFC7662) on those IDs.

  • Account, one login in Open Console. Collects personal Identities, memberships of Groups, collected Proofs, own published Services, and established Contracts.

  • (Personal) Identity, a collection of personal data for the owner of the Account.

  • Group (Identity), a collection of identities which together maintain organization data.

  • Provider (is a Group), owns one or more Service definitions within Open Console.

  • Application, is an instance of the (web)service which is operated by the Provider. One service may run in a cloud of servers, which can each separately login as Application.

  • Service, describes which requirements need to be fulfilled for an Identity to get access to an Application of the Provider

  • Session, is linking the Application with the Service definition.

  • Contract, contains the agreement between the Provider and a personal Identity or a group to use a Service. The Contract lists which information is needed, and states license and other facts typically found in a paper contract.

  • Comply groups the information which is actually used to apply the Contract: it contains the actual data which is shared with the Application.

  • Grant, is a token which represents the access to the Application. It captures facts from the Account, personal and optional group Identity, the Contract, and administrative facts like expiration. The Application may wish to refer to the Grant as "user" or "identity" in the OpenID sense.

Only Sessions and Grants (both are temporary) and Contracts (long lasting) are visible: all other IDs stay internal in Open Console.

The flow

1. Preparation

1.1 Someone at the Provider creates a personal Account.

1.2 That person creates a personal Identity which relates to the Provider.

1.3 He/She also creates a Group which will list all people (Identities) which together manage some web-based service.

1.4 One of the Group administrators can add a Service description to the Group for that web-service.

1.5 The Service gets assigned a specific token. The Provider also configures a secret. Both are to be configured in the Application.

2. Application

2.1 API versioning plan.

2.2 When one of the instances of the Application starts, it will connect to Open Console to get a temporary Application Session token. See the Application Session REST calls.

2.3 That session token will be visible during the user login process, hence must be refreshed regularly, for instance every day.

2.4 the Provider has a website which hosts an Application. That Application contains a "Login via Open Console" button. See Login Button

3. The User

3.1 A click on login button starts an OAuth2 authentication process for the visitor (user). The User gets redirected to the Open Console "Connect" interface. See Authorization Request

3.2 When the User is not yet logged-in or registered, it needs to take that action.

3.3 Once the User is logged-in, we know the Account. Together with the application Session, we can see whether the User has recently Complied to the Service. In this case, we can immediately redirect the User to the Application.

3.4 When the User has no Contract for the Service, it needs to create one for a personal Identity or one of the Groups.

3.5 With the Contract, the User enters the procedure of Complying to the requirements: fill in the right facts to complete the Contract form. When nothing has changed, the User gets directly to the Application.

3.6 The User will be asked to check whether the Comply is still correct when the personal Identity, the Group, the Contract, or the Service has changed since last use.

3.7 In other cases, the User MAY get a few seconds chance to interrupt the automatic login, to inspect the data which is exchanged.

4. User Information

4.1 The Application receives login ID (the Comply ID), as proof that the User can access.

4.2 With the login ID, the Application can ask for the content of the Comply, with some additional information. The returned structure is called a Grant. See Structure of a Grant.

4.3 The Grant is requested via the Application Session, the back-channel in the OAuth2 sense. See Request Grant

4.4 As long as a Contract between an Account or Group with a Service exists, the Contract's ID will not change: the Provider can use it to related user visits over time. Provided user details, however, may change each time a login is established or refreshed.

Technology

  • The visitor is directed around using OAuth2 (RFC6749)
  • In the future, the side-channel messages will JSON-LD v1.1 for serialization, and JWT (RFC7519) for signing, but this is not implemented yet.
  • Messages are transported over a REST interface to the Connect server.
  • Open Console Connect actions run separately from the Open Console Owner website.

Constants

Examples on all pages show certain constants, which may change over time (as long as Open Console under this fast level of development):

  • $oc_connect is either $oc_connect_live or $oc_connect_test (OAuth2 Authorization Endpoint)
  • $oc_connect_live is https://connect.open-console.eu, but not yet available
  • $oc_connect_test is https://connect-test.open-console.eu
  • $oc_context is https://connect.open-console.eu/schema/v001

Values presented at Application login:

  • $myowner, refers to the website where people can enter Open Console. Can be used for creating links to docs etc,
  • $myaccess, endpoint to get a new Grant (OAuth2 Token Endpoint, access token)
  • $myrefesh, endpoint to refresh your Grant content (refresh token)
  • $myuserinfo, endpoint to collect the details of a Grant (OpenID-like)

Index of REST commands offered by the Connect server(s)

Clone this wiki locally