Frequently Asked Questions
At this point, you will find the most frequently asked questions from our partners. We strive to keep these questions as up-to-date and error-free as possible. If your question is not included, please do not hesitate to contact us personally via email.
Scopes
Why am I not receiving the claims of my scopes?
All approved scopes can be requested from us at any time via email.
However, please note that according claims may still be unpopulated.
Specifically, this applies to: profile, schooling_level, school_address, school_location, and school_official_id.
These values must be entered by a school administrator.
Since providing these information is optional for data protection reasons, we cannot guarantee that these claims will always be available.
All other scopes are provided by Eduplaces. We therefore recommend implementing a fallback option in case a scope or one of the claims is missing. Missing claims of scopes can manifest in two ways:
- The scope and the claim is not included at all
- The claim is included but contains a null value
The latter occurs more frequently with scopes related to the school and its address.
You can find more information about the scopes at chapter scopes.
How do I extend available scopes?
To extend your available scopes, please contact us via email. Include a brief explanation of why you need the new scope and how you intend to use it. Then, we will enable it for you.
Please note that this activation may take up to one day.
official_school_id or school — which scope should I use as a unique identifier for schools?
We advise to use the scope school as a unique identifier for schools.
The claim is always provided by Eduplaces and is guaranteed to be available.
If you need to identify the school across systems or try to match it with an existing school, you can use the scope official_school_id.
The scope official_school_id contains the school’s official ID generated by the ministries.
Note that this claim is optional and might not be granted as it must be netered by a school administrator.
Why are the members of the groups not displayed to me?
There are several possible reasons why group members are not displayed after import:
First, it should be ensured that the user performing the import is themselves a member of the group. If this is not the case, other group members may not be visible.
Another common cause is the use of normal scopes outside the IDM interface for displaying groups with their members. These scopes can only retrieve users who have already logged in. The same issue occurs when using the IDM scope users.
Example: User A logs in and is a member of Group 1. When User A views Group 1, User B is not displayed because User B has never logged in. Only after User B logs in for the first time is it known that they also belong to Group 1.
Therefore, to enable the early display of groups along with their members, the use of the IDM scope urn:eduplaces:idm:v1:people:read is recommended. The specific difference between users and people is explained in more detail in the chapter Groups and People.
IDM
Should I use the IDM endpoint user or people for importing users?
The IDM endpoint users includes all users who have granted access to the application AND have already launched it at least once.
Users who have permission but have not yet selected or opened the application will not appear here.
That endpoint is meant to be used for synchronising users without using the IDM.
Therefore, most of the time it makes more sense to use the IDM endpoint people.
This endpoint includes all users and groups that were enabled for synchronisation by the teacher or school administrator, regardless if they have already logged in or not.
Please keep in mind that, especially at IServ schools, groups are often used outside of traditional class structures. It is common to see groups such as “admins” or “teachers room”.
General Questions
What do the different URLs mean?
The technical explanation of when and where each URL is used can be found in Chapter Authorization Code with PKCE.
However, misunderstandings regarding terminology occur frequently.
To help clarify this, here is a brief list of commonly used synonyms that often lead to follow-up questions.
Commonly used name | Synonym |
|---|---|
| Launch URL | Login URL |
| Redirect URL | Callback URL |
| Backchannel Logout URL | Logout URL |
How many URLs do I have to provide?
- 1 Launch URL
- 1 Backchannel Logout URL
- As many Redirect URLs as you like
During the development of your application, URLs may change or new ones may be added.
Any changes can be requested via email and will be implemented as quickly as possible. Please note that every URL must include https://.
Why am I unable to log in with my test accounts?
First, please verify that your password is entered correctly, paying close attention to case sensitivity. The users and their passwords were provided to you when the sandbox was created.
Another common source of confusion is the existence of two different test servers:
As of February 2025, we only issue new test accounts for the server partner.demo . If you are unsure which server your test account belongs to, simply try logging in on both.
If you are unable to log in on either server and are certain your password is correct, please contact us. We will then provide you with new test accounts.
Which tests does my application need to pass to go live?
In preparation for go-live, we conduct two test phases: one prior to the migration to our production environment, and a final one immediately before going-live.
🟥 = MUST 🟧 = SHOULD 🟩= COULD
Test phase 1 - pre production:
Requirement | Description |
|---|---|
| 🟥 A working Single Sign On | The SSO integration must ensure that a user who clicks on the application tile is seamlessly redirected to the target application and is automatically authenticated. The authenticated state must be clearly identifiable within the application. The authentication flow should occur without any unnecessary intermediate steps. Acceptable exceptions include mandatory actions such as email verification or acceptance of terms and conditions. Please ensure that any potential error messages are meaningful and make sense to the end user. These messages will be the basis for user support inquiries in the event of any issues. |
| 🟥 Logging out | Even though it should be self-evident, we occasionally observe that logging out is not possible. The logout process must always work reliably and promptly. After logging out, the user should either be redirected to the application’s homepage or to a dedicated logout screen. |
| 🟥 Logging in from different schools | As in real-life scenarios, it should be possible to log in from different schools. These different schools are represented by different IServ instances, each associated with its own school ID. A common reason why logging in from other schools may fail is the varying quality of data maintained across schools. Particularly critical are the data fields that must be entered manually by a school administrator. Information such as the school’s address or official school ID is not always available or consistently maintained. As a result, logging in may work for one school but fail for another. To prevent this, it should be ensured that missing data does not block the login process. At present, there is no way for partners to test this themselves, as all provided test accounts belong to the same school. |
| 🟥 No passwords | Users must not be prompted for a password during the login process. Since Eduplaces users are expected to log in via SSO, they do not have a password. Any password prompt would negatively impact the user experience. Furthermore, password changes should not be possible later if no password has been set. A reasonable approach is to include the option to set a password within the user profile. This would allow users to continue accessing the application after finishing school and after their Eduplaces account has likely been deactivated. All other password-related interactions should be avoided whenever possible to ensure an optimal user experience. |
| 🟥 Students must not see teacher-specific content and must not be able to make any purchases. | It is crucial to distinguish between user roles. Eduplaces primarily differentiates between students and teachers. (The role OTHER exists but is currently not in use. It is intended for school-affiliated personnel such as janitors or similar roles.) When the application differentiates between students and teachers, it is essential to use the role scope correctly. This ensures that teachers are shown the teacher view, and students are shown the appropriate student interface. This distinction becomes especially important when it comes to purchasing content or subscribing to services. As a general rule: students must never be allowed to make purchases in the context of school use. This must be taken seriously and enforced with strict limitations. |
| 🟥 A working IDM usage, if implemented | When the IDM interface is used, we expect it to function properly and be used in a purposeful manner. The import process works as soon as either a working import function is available, or it is possible to import all groups and users at the time the application is activated. Whether the IDM interface is being used appropriately is primarily measured by whether the import includes and displays all users it is expected to. The most common source of errors in this context is the distinction between users and people. This has already been described above and is further detailed in the corresponding chapter Groups and People. |
| 🟧 Do not show IDs | IDs or other technical data should not be displayed anywhere in the application unless they are explicitly labeled as such. A common issue is that unique identifiers are included in names or email addresses when the actual name is unknown. In such cases, an alternative solution should be implemented that provides a more user-friendly display. |
| 🟧 Logout with multiple tabs | When a user operates the application in multiple tabs, logging out in one tab should automatically log them out in all tabs. This is intended to prevent situations where students or teachers forget to log out completely, leaving sessions active that could potentially be misused by other individuals. |
| 🟧 Backchannel Logout | Another measure to prevent misuse of forgotten logins is the implementation of a backchannel logout. This ensures that a user is automatically logged out of your application when they log out of Eduplaces. To implement the backchannel logout, we require a logout endpoint URL from your side. More details about the logout mechanism and how it works can be found in the chapter Logout. |
Test phase 2 - pre going-live:
At this point you passed the first testphase and moved to production.
All test cases from the initial test phase are re-executed at this stage. Ideally, there should be no deviations from the previous results. Additionally, the following points are also included:
Requirement | Description |
|---|---|
| 🟥 A working login button. | This button must trigger SSO for Eduplaces users and follow a design proposed by us. If our designs do not fit well with your existing style, we kindly ask you to consult with us before making any adjustments. The most important aspects are that the Eduplaces logo is included and that Eduplaces is spelled correctly. You can find the button style guide in the chapter titled Login Button. Please note that there may be situations where two of these buttons exist. This can occur, for example, when a user lands on a logout page after logging out. This page differs from the page a user can log in from. Both buttons must initiate the SSO process and allow users to access the application via Eduplaces. |
| 🟥 Native App | If your application includes a native app, 3 additional aspects will be tested at this stage: + Single Sign-On must function without errors. + The app must include a “Login with Eduplaces” button. + The user should be redirected to the native app immediately after leaving Eduplaces. This can be achieved via a landing page that detects whether the user is on a mobile device and whether the app is installed. As a recommendation, we suggest implementing Deep Links for Android and Universal Links for iOS to ensure seamless redirection to the native application. |
| 🟧 Onboarding 10 Thesen | Based on feedback from users who felt lost when first using and testing applications, we now check whether there is an informative and engaging onboarding process. The onboarding should briefly and clearly explain what the app does and how users can get started with the first steps. To support our partners in creating effective onboarding experiences, we have developed a set of guiding principles that define what good onboarding should include. These principles can be provided upon request, but in most cases, we already share them after the first testing phase. |
Is your question not included or insufficiently answered? Contact us via email, and we will personally address your question.