Connect Brightspace (D2L)

This guide covers the full Brightspace (D2L) setup, in the order the screens have to be completed. Everything you need is on this page. Setup takes about fifteen minutes.

Work through the steps in order. Step 2 asks for the client ID and client secret that step 1 produces, so starting at step 2 does not work.

What you are setting up

Odea needs two separate credentials, and Brightspace keeps them on different admin pages.

Object	What it does	Where it lives
OAuth app	Lets Odea read course materials and class lists	Admin Tools → Manage Extensibility → OAuth 2.0
Registration	The trust relationship: our URLs, our keys, your issuer	Admin Tools → Manage Extensibility → LTI Advantage
Deployment	Which org units the tool is switched on for	Admin Tools → External Learning Tools → LTI Advantage
Link	The thing an educator or student clicks	Created from the deployment, or by an educator in the course

The OAuth app and the registration are not interchangeable. A working launch with no OAuth app looks correct until someone tries to import course content, and finds nothing.

Step 1: Register the OAuth app

This produces the client ID and client secret that step 2 asks for.

The redirect URI

After a user approves access, Brightspace sends the browser back to Odea. The redirect URI must match what you register character for character:

https://odea.education/oauthresponse

No www prefix

Odea is at odea.education. Requests to www.odea.education are redirected to the non-www host, but OAuth providers compare redirect URIs literally, and www fails the comparison. Register https://odea.education/oauthresponse exactly as written.

Create the application

1. Go to Admin Tools → Manage Extensibility and open the OAuth 2.0 tab.

2. Click Register an app.

3. Leave Grant Type set to Authorization. Do not choose Client Credentials.

4. Set Application Name to something you will recognise later, for example Odea Course Sync.

5. Set Redirect URI to the URL above.

6. Paste this into Scope, as one space-delimited line:

   users:own_profile:read enrollment:enrollment:read enrollment:orgunit:read orgunits:course:read content:toc:read content:file:read managefiles:files:read role:detail:read

   Every scope is read-only. They cover the signed-in user’s profile, their course list, course details, the table of contents, file downloads, class lists, and role mapping.

7. Leave Access Token Lifetime at 3600.

   Enlarge

   Grant type, redirect URI and scope are the three fields that have to be right.

8. Leave Prompt for user consent and Enable refresh tokens ticked. Both are on by default. Refresh tokens are what keep an educator from signing in again on every sync.

9. Tick I accept the API Developer Agreement. Register stays disabled until you do.

10. Click Register.

    Enlarge

    Register is disabled until the developer agreement is accepted.

Copy the credentials

Open the new application from the OAuth 2.0 list. The Client ID and Client Secret are on the detail page.

Enlarge

The client secret stays readable on this page, so anyone with access to Manage Extensibility can read it.

Before you start step 2

• I have the client ID
• I have the client secret
• The redirect URI is registered exactly as written

Step 2 asks for both values partway through the registration dialog. There is no way to supply them beforehand, and no way to complete the registration without them.

Send the secret through Odea, not by email

Paste the client secret into the registration dialog, or later into Admin dashboard → Settings. Do not send it to us by email or chat.

Step 2: Register the tool

There are two routes, both on the Register Tool screen.

Dynamic registration

Recommended. You paste one URL, and Brightspace and Odea agree every endpoint, key and claim between themselves. Nothing is typed by hand and nothing is copied back.

1. Go to Admin Tools → Manage Extensibility → LTI Advantage.

2. Click Register Tool.

3. Choose Dynamic, not Standard.

4. In Tool initiation registration endpoint, paste:

   https://production-backend.odea.education/lti/register

5. Leave Configure Deployment ticked. It is ticked by default. Step 3 covers the deployment settings that only you can choose.

6. Click Register.

7. When Odea’s dialog asks for them, paste the client ID and client secret from step 1.

Enlarge

Dynamic registration needs one URL and nothing else.

Brightspace then contacts Odea, and Odea registers itself. The tool appears as Odea, with the domain, redirect URL, OpenID Connect login URL and keyset URL already filled in, plus a client ID Brightspace generated.

Leave every Extension off. Assignment and Grade Services, Names and Role Provisioning, and Platform Notification Service are all unused, and enabling them grants access Odea neither needs nor wants.

What the registration requests. Three claims: the issuer, a stable user identifier, and the user’s email address. Brightspace also sends the course context and the user’s role with each launch. Nothing else.

Requesting the email claim is not the same as being granted it. Brightspace decides that separately, per deployment, under Security Settings. Step 3 covers it.

Manual (Standard)

Use this route only if institutional policy forbids dynamic registration. It reaches the same place, but every value below is one you enter yourself, and the resulting identifiers are not something Odea can discover. This route ends with an email to us, and does not work until that email arrives.

1. Go to Admin Tools → Manage Extensibility → LTI Advantage.

2. Click Register Tool and choose Standard, not Dynamic.

3. Enter these four values:

   Field	Value
   Domain	https://production-backend.odea.education
   Redirect URL	https://production-backend.odea.education/lti/launch
   OpenID Connect Login URL	https://production-backend.odea.education/lti/login
   Keyset URL	https://production-backend.odea.education/lti/jwks

4. Leave every Extension unticked.

5. Click Register.

6. Email [email protected] with the client ID, the deployment ID, and your issuer.

7. Enter the OAuth client ID and secret from step 1 under Admin dashboard → Settings once your institution has been approved.

Nothing launches until those three values reach us

Dynamic registration identifies your institution as part of the handshake. A manual registration does not, so until that email arrives there is no way to match a launch to your institution.

Step 3 is the same for both routes.

Step 3: Create or check the deployment

A registration tells Brightspace that Odea exists. A deployment makes it usable, and holds the two settings that matter most: which courses the tool covers, and what Brightspace is allowed to tell it about the person launching.

Two boxes are unticked on every new deployment

Email, under Security Settings, and Open as External Resource, under Configuration Settings. Both are off by default, and a deployment missing either one looks fully configured. Without Email the launch is rejected; without Open as External Resource the tool loads a blank frame. They are steps 5 and 6 below.

Enlarge

A correctly configured deployment: Email ticked, Open as External Resource ticked, nothing else.

1. Go to Admin Tools → External Learning Tools → LTI Advantage.

2. Look for a deployment whose Registration Name is Odea. The list opens on the Enabled filter, so switch to All first.

3. If a deployment exists, open it. If none does, click New Deployment, then on the Deploy Tool page choose Odea under Tool and give the deployment a Name, such as the faculty it serves.

   Enlarge

   A deployment is created against a registration you already have. The Tool dropdown lists your registered tools and nothing else.

4. Leave every checkbox under Extensions unticked. Assignment and Grade Services, Names and Role Provisioning Services, Platform Notification Service and Asset Processor are off by default, and Odea uses none of them.

5. Under Security Settings, tick Email, and leave every other box in that section unticked. Odea identifies people by email address, and a launch that arrives without one cannot be completed.

6. Under Configuration Settings, tick Open as External Resource. This makes Odea open in its own tab.

7. Switch Auto Migrate Links on. It is off on a new deployment. This is Brightspace’s own mechanism for carrying LTI links across course copies, and it saves educators rebuilding links every semester.

   Enlarge

8. Set the scope under Make tool available to, as described in step 4.

Before you save the deployment

• Email is ticked under Security Settings
• Open as External Resource is ticked under Configuration Settings
• Every Extension is unticked
• Auto Migrate Links is on

The first two are the ones that fail in production. Neither is on by default, and neither is visible from anywhere except this page.

What the deployment shares, in full

Security Settings is the complete list of what Brightspace hands over:

Setting	Odea’s use
Email	Required. It is how an account is matched or created.
Name, and First Name / Middle Name / Last Name	Not used. Leave unticked.
User ID, Username, Org Defined Id	Not used. Leave unticked.
Classlist including users not known to this deployment	Not used. Leave unticked.

Independently of these boxes, every LTI launch carries the issuer, the deployment, a stable pseudonymous identifier for the user, the course context and the user’s role. Those are part of the LTI protocol rather than settings you control here.

Each deployment also has its own Deployment Id, shown under Brightspace Deployment Details, separate from the registration’s client ID. One registration can carry several deployments, for example one per faculty with different org unit scoping. Odea accepts new deployment IDs from a registration it already trusts, so a new deployment needs no message to us.

Step 4: Decide which org units Odea covers

This sets which courses Odea appears in. Brightspace expresses it entirely through Make tool available to at the bottom of the deployment.

Click Add Org Units. The dialog lists your org units with a Type column and, for anything that can contain other org units, a set of Options:

• This org unit covers the node itself and nothing beneath it.
• All descendants covers everything beneath the node but not the node itself.
• This org unit and all descendants covers both.

A course offering has no options, because nothing sits underneath it.

Enlarge

Every row that can contain other org units starts on This org unit. The list is truncated here; a real instance shows every org unit.

Every row starts on This org unit

Ticking a department or a semester and clicking Add without changing the radio button scopes Odea to that node alone. No course inside it is covered, nobody gains access, and the deployment still reads as configured.

For anything other than a single course offering, select This org unit and all descendants before clicking Add.

Each choice then appears as its own line, worded to match what you selected. This org unit and all descendants produces two lines, one for the node and one for everything under it.

A new deployment arrives with The Organization already in the list. Remove it with the cross beside it for anything narrower than an institution-wide rollout. A removed line stays visible with a line through it and a plus to restore it, so the change is reviewable before you save.

Enlarge

The Organization has been removed, a whole department added with its descendants, and one further course offering added on top.

How you combine these depends on the size of the rollout:

• A pilot. Remove The Organization and add only the participating course offerings. Each is a single line covering exactly one course.

  Enlarge

  A pilot scope: one course offering, nothing else.

• A faculty-wide rollout. Remove The Organization and add the faculty’s department or semester with This org unit and all descendants.

• An institution-wide rollout. Add the organisation itself with This org unit and all descendants, so a second line reading Every Org Unit under The Organization appears next to it. The line a new deployment starts with names the organisation on its own, which is not the same thing.

Brightspace has no exception that removes access. The list is additive: a course is covered when something in the list covers it, and excluded otherwise. To keep one course out of an otherwise faculty-wide rollout, add the individual courses that should have Odea rather than the department, or move that course to an org unit outside the scope.

If you scope a deployment to a single test course now, widen it before going live.

Step 5: Create a link

The deployment makes Odea available. A link is what people click. A link has to exist before anyone can launch Odea, but it does not have to be you who creates it.

As an administrator, create one link from the deployment page with View Links → New Link. Educators then pick it from a list and never see this form.

As an educator, in the course open Content, choose Add Existing on a module, and pick External Tool Activity. Any link an administrator already created appears there. Create New LTI Link opens the same form as below.

The form asks for four things:

Field	What to enter
Deployment	The Odea deployment from step 3. Required, and not preselected.
Name	What people see in the course, for example Odea.
URL	https://production-backend.odea.education/lti/launch
Description	Optional. Leave it empty.

Enlarge

One URL for every link, every course and every deployment. It never varies.

The URL is the same everywhere

It is Odea’s launch endpoint, not a per-course or per-institution address. The course is identified by the LTI claims Brightspace signs into the launch, not by anything in this URL, so there is nothing here to customise.

Odea validates both the host and the path of the URL a launch arrives with. A different address, or /lti/launch/ with a trailing slash, is rejected rather than silently opening the wrong thing.

Enlarge

Inside a course, the dialog lists the LTI link next to the deployment it came from. A course outside the deployment's scope shows nothing here.

That list is the clearest test of your scoping. If Odea does not appear for a course you expected it to cover, the deployment’s org unit scope is the cause, not the link.

The admin work is complete at this point.

Which API versions your instance supports

Odea reads this from your instance during approval and pins the versions it confirms, so there is normally nothing to do here. You need it in two cases: we could not reach your instance at approval time, or D2L support asks which versions you are on.

Your Brightspace address

Look up

Instance not reachable from here? Paste the JSON instead

Open https://<your-host>/d2l/api/versions/ in a browser, copy everything, and paste it below.

Read pasted JSON

Why not just the newest version

Brightspace keeps every older version working, so only a version above your ceiling fails. The newest is therefore safe to call but not safe to assume: response shapes change between versions, and a version newer than Odea expects can return fields it does not read. The lookup picks the highest version at or below what Odea was built against, which is the same rule approval applies.

The lookup runs entirely in your browser against the address you enter. Nothing is sent to Odea and nothing is stored.

Step 6: Institution verification

Brightspace instances hosted by D2L sit on a brightspace.com address. That address identifies D2L rather than your institution, so the institution behind a registration cannot be verified automatically. Registrations from these instances are reviewed by a person before they go live.

Odea asks for a contact name and email during registration. Fill it in and we confirm the connection, typically within one working day. Launches show a holding message until then.

If your Brightspace runs on your institution’s own domain, verification is automatic and the connection is live immediately.

What educators and students see

The first educator to launch Odea from a course reaches a setup page, where they link the Brightspace course to Odea and choose which materials the AI may use. This takes a few minutes and happens once per course. Every launch after that goes straight into the course.

A student who launches a course the educator has not set up yet sees a page explaining that the course is not ready. They never see an error, a blank screen, or another course’s content.

Course copies and new semesters

Brightspace assigns a copied course a new context ID. Odea resolves the course from the launch every time rather than binding it to the link, so a copy is treated as a new course: the educator is walked through setup again, and students see the “not ready yet” page until that is done.

Launches never break, and they never silently serve the previous semester’s materials.

Troubleshooting

Brightspace-specific problems are below. For issues common to every LMS, see Troubleshooting LTI launches.

The tool opens a blank frame or spins. Open as External Resource is unticked on the deployment. See step 3.

Launches work, but no course materials appear. The OAuth app is missing or its credentials were never entered. See step 1, then Admin dashboard → Settings.

Educators cannot find Odea in their course. No link has been created, or the deployment’s org unit scope does not include their course. See steps 4 and 5.

A newly created faculty cannot launch. Its org unit is outside the deployment’s scope. Add it under Make tool available to.

A whole department was added but none of its courses can launch. The org unit was added with the default This org unit option, which covers the department node alone. Add it again with This org unit and all descendants. See step 4.

Launches report that no email address was sent. Email is unticked under the deployment’s Security Settings. It is unticked on every new deployment. See step 3.

A deployment you created cannot be found. The LTI Advantage list opens on the Enabled filter. Switch to All.

The OAuth consent screen reports an invalid redirect URI. The URI registered in step 1 differs from the one Odea sends, usually by a www prefix or a trailing slash.

Data and privacy

• Received per launch: issuer, a stable user identifier, email address, LTI role and course context. Nothing else. The email address is the only one you switch on yourself, under the deployment’s Security Settings.
• Received through the OAuth app: course content, materials and class lists, for the courses educators choose to connect. Every scope is read-only.
• Hosting: processed and stored in the EU on Google Cloud. Encrypted in transit (TLS 1.2 and above) and at rest (AES-256).
• No data resale, no advertising, no behavioural monetisation, as a contractual commitment.

Full detail is in the Trust Center and the privacy policy.