Tokens for login into web services


Adding transcript text Here for easy reference
"Deepak added a token to authorize to the webservices. You login once, get back a token and this token allows to keep the session open in iDempiere and not authorize with every request. We create a new table to keep the tokens. It would be good if we can keep the whole session of the webservices request for the following requests. Deepak did not yet finish his work. (JIRA)
When a client logs in to the webservice it can use both ways of authentication: Give all credentials or use the token. You can even give both to automatically login again if the token expired"

Here is my full proposal.

In Login section of request, We should make all field other then username as optional. Add one more optional field as token.

When first time webservice request made, it should contain all login information except token. Response of such login will have Token. Client can send next call with just userName and token. This token will be expired in configurable time.




Carlos Ruiz
November 16, 2015, 5:37 PM

Hi, as we talked at Bischofstein castle one of the main goals defined was to implement reusability of the session, and as per review this ticket is not achieving that goal.

We talked about that on the IRC meeting:

/ , I opened ticket and uploaded a test patch to achieve such goal. Any feedback is welcome.


Carlos Ruiz

Tomáš Švikruha
November 18, 2015, 7:35 AM

Hi , I tested only reusability of tokens - not sessions. Better answer should give us

Carlos Ruiz
November 19, 2019, 6:15 PM

Hi, revisiting this, I think we must implement support for known standards like OAuth2 or SAML.

Does the patch follows any of the standards?

As we’re talking now about implementing REST, I think is important also to implement OAuth2 as the authorization for REST?


Carlos Ruiz

Norbert Bede
November 20, 2019, 6:14 AM



What we have done

  1. We rethink/extend logical model (add some new fields like token type (refresh, access etc.), token provider (3th party like aws cognito, internal uuid, FB etc.) - so we are using it as all token types and expiration database for all providers.

  2. Then we wrote a process - must be rewritten and refactored as OSGI service/endpoint (also as gui like google - “login by FB account”)

  3. We added an important object User Identity make 1:N relationship between eg. User1= Ident1(FB) Ident2(LinkedIN) - however not too much code behind related to FB, LinkedIN - but logically we don’t prefer connect AD_User against 1 external identity

  4. Supported Processes

    1. mostly submit email password get oauth2 tokens (Refresh/Access)

    2. we are allowed set timeouts

    3. we are able to send JWT token format as body

    4. we are able to return context as scope well.

    5. etc..

Oauth2 is a huge specification we are implemented - hope well - however this is a complex implementation project itself. We had luck our colleague wrote that time Oauth2 server for a local bank - so we discussed a lot - however - can’t follow everything because time/budget.

We are using it in production from 2016 so lot of experience, known issues, requirements.

We have no experience with SAML.

If help, we can make clean the code, then share in private for now as an example implementation.

Deepak Pansheriya
November 22, 2019, 5:28 AM

when implementing Auth token, we did not followed oAuth2 standard and till I have not read oAuth2, so not sure how close we are with oAuth2. But we are using Auth token with following scenarios


  1. NodeJS based app use iDempiere server to authorize

here is sequence diagram explaining the use case. I am thinking this is nearest match to what oAuth2 do.


1.1 Here mobile App which use nodeJS as backend, used to authenticate with iDempiere server by normal web service having ADlogin in request

1.2 iDempiere returns Auth token

1.3 App send request to NodeJS server with AuthToken.

1.4 NodeJS server validate Authtoken with iDempiere server using ADLogin request

1.5 if Authtoken is valid then iDempiere service return success, So NodeJS server allow operations based on authorization from iDempiere service.

2. Manual Auth token used in third party app integration

This is second use case where we use auth token to configure credentials in third party application like Magento. Instead of providing AD_Org, Warehouse, AD_client, AD_Role and user name and password, Authtoken reduce it to have only Username and password stored in third party application. Third party application send web service request with Username and Auth Token only.


3. We have third kind of use case is to allow temp access to outsider. One use case we implemented through webstore is confirmation of vendor PO. Where once Purchase order is completed, we generate 3 days valid Auth token and send email with link to confirm PO. once PO is confirmed by Vendor, we mark Auth token as expired.


I may need some time to read about oAuth2 and JWT for additional suggestions.


what you mentioned is for supporting authorization by third party. For example using oAuth2 for authenticating user by Google, face book or linked in. this may be other use case of oAuth2 but this may be different effort and we should not use Authtoken for that. For example if we are syncing user calendar with google calendar, then we needs user to authenticate with google. we are working on design for same and we can add this feature where one user can have multiple oAuth2 depending on oAuth2 provider.



Deepak Pansheriya


Diego Ruiz

Tested By