'SURFconext's API Security offers more possibilities, it makes our own infrastructure simpler and more up to date. It saves us a layer of management and the additional responsibility.'
Students at the University of Amsterdam (UvA) and the Hogeschool van Amsterdam (HvA) use a student app to check their schedule, grades and study progress. This data comes from other systems than the app itself, for example the student information system. By means of APIs, the data is retrieved. But before they are shown in the app, the API must be able to reliably establish the student's identity. This is personal data, which must not fall into anyone else's hands. It should not happen, for example, that a student sees the grade of a fellow student in the app. To protect APIs containing sensitive personal information, the UvA and HvA now use API Security from SURFconext. This ensures that APIs 'know' whether the right person is requesting sensitive data.
How it works
For a number of years, SURFconext supports OpenID Connect (article in Dutch), an authentication and authorisation protocol suitable for mobile apps. The student app of the UvA/HvA is connected as a service to SURFconext via OpenID Connect. The data a student can see in this app (grades, schedules) are retrieved by the app from different source systems of the UvA/HvA via APIs. These source systems are also registered separately at SURFconext as ‘resource servers‘. After a successful login to the app, the app receives an access token from SURFconext. The app can use this token to make a request to the APIs of the source systems to retrieve, for example, grades for the logged-in user. The API needs to verify that the access token is valid and also wants to be able to reliably identify the user associated with the access token. The API does that via API Security from SURFconext - that's where the token was issued and therefore where it can be made sure the access token hasn't been tampered with.
One less management layer
We used to have our own authorisation infrastructure for this purpose, which was linked to SURFconext," says Tom Kuipers, a developer at the UvA and HvA ICT Services department. We needed an extra step to verify the identity and we had to keep the server up and running ourselves. SURFconext's API Security offers more possibilities; it makes our own infrastructure simpler and more up to date. It saves us a layer of management and the additional responsibility.
For users, the application of SURFconext API Security is both accessible and safe. A student only needs to log in once to always be able to use all the functionalities in the app. For this authentication, the student app refers to the institution's central login page, to which SURFconext is connected by default. According to Kuipers, this browser screen provides 'a bit of awareness. We encourage our students not to just leave their student details in an app. Thanks to the link with the padlock next to it, they can check whether it comes from a trusted party. Not an unnecessary luxury in a time when higher education institutions are regularly targeted by hackers.'
'Don't try inventing your own security, but make use of the standards that are available. All the functionalities that are regarded as standards in the industry are included in the SURFconext platform.'
The UvA's own authorisation infrastructure had the advantage that matters concerning Trust & Identity were arranged within the institution and were not shared with third parties. But in 2021, SURFconext's OpenID Connect is the way to go,' says Kuipers. 'Don't go inventing your own security, but make use of the standards that are available. All the functionalities that are regarded as standards in the industry are included in the SURFconext platform. We can use the app to hitch a ride on that.'
Kuipers is also enthusiastic about the dashboard, which allows an institution to set up the service independently. He has already gone through that process for the UvA, and is still in the middle of it for the HvA. At the stage where you need to convert an app, it is nice to be able to do it quickly,' he says. He does envisage the possibility of an extra functionality in the dashboard: a button with which he can declare a token invalid. That would come in handy in case a student loses a phone. At the moment, invalidating a token still has to be done manually via SURF.
Text: Marjolein van Trigt