Built-in OAuth 2.0 Flow in Mendix - Mendix Forum

Built-in OAuth 2.0 Flow in Mendix

53

Most API are protected by the OAuth 2.0 standard (or should be). It would be very helpful if Mendix integrates this flow into the REST call action from the client perspective (similar to what Postman does) and also implement it in the REST Published Service from the server-side.

 

From the REST Call action:


 

Under the Authentication section or in a new Authorization section, we should add an option to configure the OAuth 2.0 parameters. similar to Postman:

 

The idea for this action is to cache or store the token while is valid and automatically use it as an Authorization header to perform the call. it will also handle the refresh token in case the existing one has expired.

 

From the Published REST Service:

Mendix currently has a section to configure some Authentication. Ideally, we would have an option here for OAuth 2.0, where you can add the introspect URL to validate the token, but also, Mendix should cache/store the token while is valid to avoid unnecessary calls to introspect. If the token is not valid Mendix should have a default 401 or 403 HTTP response.

 

 

A nice-to-have would be an option to also set your own microflow to validate the token that returns true or false.

asked
5 answers

Great idea. Please prioritise.

Created

going to add that: if we could import a postman collection into mx, that would save a lot of time and troubleshooting :D 

Created

👍.

Created

Hi Leonardo,

 

Thanks for sharing your suggestion!

We have recently released the OIDC SSO with platform support.
A next step is to make API-calls more easy by passing the obtained token (access token) to services/APIs via the Auth*n header.
I’m currently thinking of first solving it for tokens that are JWTs (without introspection) and then in a next step add the possibility to do introspection or even call UserInfo endpoint.

I cannot give any ETA yet, but wanted to confirm it’s on our radar.

Thanks

 

Jaap

Created

Let's include it in SOAP services as well then! ;-) Custom authentication options there currently do not allow proper response code/reasons to be set when the user is not successfully authenticated. (server 500).

Created