Feature #1233
openAPI: External Authentication
Description
External Authentication will be needed for projects who want a frontend without exposing all data (no public API).
For implementing an API authentication method see: Whitepaper, authentication-with-flask
To consider: webclients will request data so we can't e.g. just block IPs or similar.
Updated by Bernhard Koschiček-Krombholz over 4 years ago
- Description updated (diff)
Updated by Bernhard Koschiček-Krombholz over 4 years ago
- Status changed from New to Assigned
Updated by Bernhard Koschiček-Krombholz over 4 years ago
- Target version set to 208
Updated by Bernhard Koschiček-Krombholz over 4 years ago
- Description updated (diff)
Updated by Bernhard Koschiček-Krombholz over 4 years ago
- Subject changed from External Athentification to External Authentification
- Status changed from Assigned to Acknowledged
For the moment postponed!
Updated by Alexander Watzinger over 4 years ago
- Status changed from Acknowledged to Assigned
Updated by Bernhard Koschiček-Krombholz over 4 years ago
- Target version changed from 208 to Wishlist
Updated by Alexander Watzinger about 4 years ago
- Subject changed from External Authentification to API: External Authentification
- Status changed from Assigned to Acknowledged
- Assignee deleted (
Bernhard Koschiček-Krombholz)
Updated by Christoph Hoffmann about 4 years ago
- Subject changed from API: External Authentification to API: External Authentication
Updated by Bernhard Koschiček-Krombholz about 4 years ago
- Assignee set to Bernhard Koschiček-Krombholz
Updated by Alexander Watzinger about 4 years ago
- Description updated (diff)
- Status changed from Acknowledged to Assigned
- Target version changed from Wishlist to 208
Moving this from wishlist again because we'll need it for projects who want a frontend without exposing all data.
Updated by Alexander Watzinger about 4 years ago
I was thinking about the authentication issue. The API is either accessible (public) or not and authentication via frontend gets tricky because requests are sent from some web client.
We will have to solve this at some point but we can deal with it for now:- For testing we can use the Origins project, it has a small data set (so less likely performance issues) and the API is already set public.
- For concluded projects it shouldn't be a big issue, e.g. the demo versions MEDCON and DPP are already cleaned up data wise and open anyway (nevertheless we will ask for permission).
- THANADOS is a case where we have a public frontend but not all data should be accessible BUT because the THANADOS frontend uses Flask we could implement an IP restriction (#1377)
Updated by Bernhard Koschiček-Krombholz about 4 years ago
- Related to Feature #1377: API: IP restrictions added
Updated by Alexander Watzinger over 2 years ago
- Status changed from Assigned to Acknowledged
- Assignee deleted (
Bernhard Koschiček-Krombholz) - Target version changed from 208 to Wishlist
Updated by Alexander Watzinger about 2 months ago
- Status changed from Acknowledged to Assigned
- Assignee set to Bernhard Koschiček-Krombholz
- Target version changed from Wishlist to 8.11.0
Updated by Bernhard Koschiček-Krombholz about 1 month ago
- Status changed from Assigned to In Progress
- Target version changed from 8.11.0 to 8.9.0
Branch: feature/jwt
I implemented basic authentication with jwt tokens. A user can create a token (currently 1 day, 90 days or no expire) and can use it as jwt token to access the API even if it is not public.
The information about the token is stored in the database.
Todo:- Revoke tokens
- Refresh tokens (if needed)
Updated by Alexander Watzinger about 1 month ago
After a meeting with Bernhard we decided following adaptions:
- Check if tokens can be copied if transferred via a web request
- Token generation
- Only for admins (at least for now)
- Move form to admin area
- Table select for user_id
- Save current user in an additional table field (e.g. creator_user_id or similar)
- Change token input field
- Remove from insert
- Show in grey text area after creation but keep the handy copy button
- Token list view
- Add delete column (with JavaScript confirm)
- Add creator column
- Sort and mark active tokens that are:
- User has to exist and be active
- Valid to date has to be in future
- Not revoked
Updated by Bernhard Koschiček-Krombholz 29 days ago
- Check if tokens can be copied if transferred via a web request
I've tested it and looked into it further; the Authorization header does not appear in the browsers' developer tools. Clearly, there are ways to get those tokens, but the effort would be higher than to crawl the existing presentation site with a script. And since we host open data projects and the access token from a presentation page is strictly read-only, I believe this security measure is adequate.
Updated by Bernhard Koschiček-Krombholz 17 days ago
- Target version changed from 8.9.0 to 8.10.0