Refresh token to acquire new access token

[Swapnil M Mane]

Hello all,
When a token is expired, we generally redirect the user to the login
screen, but it is not a good user experience, especially when a user
is in the middle of executing any business process.

To handle this and avoid authentication with username and password again,
In OAuth2 [1], the concept of the refresh token [2] was introduced.

Refresh tokens are credentials used to obtain access tokens.
Refresh tokens are issued to the client by the authorization server
and are used to obtain a new access token when the current access
token becomes invalid or expires.
The life of the refresh token is much higher than the access token and
it can be used only to get a new access token, and not able to access
any other resource on the server.

In Moqui, do we any similar kind of implementation or is there any
recommended way to handle the expired token gracefully for REST APIs?

If you have any inputs or suggestions on how to handle the expired
tokens and reauthorize the user for the REST API calls without
enforcing to provide the username/password credentials again, please
let me know, thank you!

[1] https://tools.ietf.org/html/rfc6749
[2] https://tools.ietf.org/html/rfc6749#section-1.5

Best Regards,
Swapnil M Mane

[Warnock, Matt]

I had a discussion with David about this the other day. In particular,
when editing a Wiki page, such as an SOP, it is really annoying to
have your session time out, causing you to lose all your work and be
redirected to the login page. The workaround seems to be to save your
work more often, which clutters the DBMS with needless copies of
versions that don't really need to be saved. Instead, I have taken to
copying the content to a word document for editing and pasting it
back, which hardly feels ideal either.

I will also note in passing that not being able to preview or print a
rendered version of the Wiki page from the edit screen is a problem. I
would love to see that issue addressed as well. Perhaps Joe can help
with that item next?

> --
> You received this message because you are subscribed to the Google Groups "Moqui Ecosystem" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to moqui+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/moqui/CAOwvvyfXq%3DeBSyAxVi0EGCt2kiDNh-nDqD7xNjEiv2LC5AxZAw%40mail.gmail.com.

[Swapnil M Mane]

Hi Matt,

Thank you for sharing your experience.

Just to be on the same page, my query is related to tokens for REST API,

whose hashed we store in moqui.security.UserLoginKey entity.

So, I am looking for a solution to this, i.e. how we can use the concept of

refresh token or similar conect to gracefully handle the expiration of this token.

Best Regards,

Swapnil M Mane

To view this discussion on the web visit https://groups.google.com/d/msgid/moqui/CABg-jjtAHNdASbLWwHAUw2LOGT4vkpoNKjBgOxKj0wvdVChp-g%40mail.gmail.com.

[Warnock, Matt]

Sorry if my response was off topic. As you mentioned the user
experience, I assumed it dealt with the expiration/timeout of the user
session. Thanks for the clarification.

> To view this discussion on the web visit https://groups.google.com/d/msgid/moqui/CAOwvvyfYM_3X3CT%3DMUK9Abia5Sww81%2BSuQyGq0eCPVF9Cz-MsA%40mail.gmail.com.

[David E Jones]

Hi Swapnil,

What sort of client is talking to the Moqui server? Why are you using access tokens (api_key)?

Does OAuth2 have anything to do with your scenario, ie being designed to allow users to authorize access by external systems or applications that are not otherwise trusted?

-David

[Swapnil M Mane]

Thanks, Matt.

Hi David,

Please refer to my comments inline.

On Thu, Dec 31, 2020 at 9:57 AM David E Jones <d...@dejc.com> wrote:

Hi Swapnil,

What sort of client is talking to the Moqui server? Why are you using access tokens (api_key)?

We are having two types of applications talking to the Moqui server:

1.) Mobile Apps built with Ionic framework [1]

2.) Standalone headless frontend, build with Vue Storefront [2]

We are using access tokens (api_key) for authorization purpose and the process is something like this,

a.) From the above-mentioned applications, first we hit the login API by providing username and password.

This login API validates the user by

`ec.user.loginUser(username, password)`  method

and on successful authentication get the login key (access token) from

`ec.user.getLoginKey()` method

and return it to app.

b.) After this for all the subsequent requests,

we pass this access token (api_key) in the request header in api_key field.

Does OAuth2 have anything to do with your scenario, ie being designed to allow users to authorize access by external systems or applications that are not otherwise trusted?

No, OAuth2 has anything to do with my scenario, I shared it just for reference purposes,

how they use the refresh token concept to get a new access token when it is expired.

Please let me know if you need any additional information, thank you!

[1] https://ionicframework.com/

[2] https://www.vuestorefront.io/

 

To view this discussion on the web visit https://groups.google.com/d/msgid/moqui/CAKBdU9cVqBK4Jg%2B4cOHoULoV_g_QBeT%2BiuiW%3DkdRnps2DZ0Fcw%40mail.gmail.com.

[aabiab...@gmail.com]

Hi Swapnil,

Moqui does not currently support OAuth per say. The api_key is intended primarily for system-to-system authentication and is designed to have a long life span. It is not recommended for client authentication at all for the following reasons:

1. The api_key is like a password, anyone who has this key can call APIs on the server freely!
2. API keys have a fixed validity and that validity is not extended following each API call (contrary to the normal HTTP session). This will force end users to login again once the key expires. This is a bad user experience.

The recommended approach for integrating such clients with Moqui is using the JSESSIONID cookie and not the api_key. The flow would be something like this:

1. Client send the username/password and retrieves the JSESSIONID cookie and sessionToken
2. All subsequent requests send the JSESSIONID cookie and the sessionToken in case the request is an HTTP POST
3. Client can later logout using the builtin /rest/logout API

-- 

Regards,

Ayman Abi Abdallah

[Swapnil M Mane]

Hi Ayman,

Thank you so much for the detailed insights and inputs.

I will have a deeper look into the direction you stated and get back to the group if found anything new.

Best Regards,

Swapnil M Mane

To view this discussion on the web visit https://groups.google.com/d/msgid/moqui/e75c5bc518bfcab5cf768fe43ed834cf22cf05f4.camel%40gmail.com.

[Deepak Dixit]

Thanks Ayman for the detail, it helps a lot.

Kind Regards,

Deepak Dixit

DIRECTOR OF PRODUCT ENGINEERING

mobile: +91 9826754548

email: deepak...@hotwax.co

www.hotwax.co

To view this discussion on the web visit https://groups.google.com/d/msgid/moqui/e75c5bc518bfcab5cf768fe43ed834cf22cf05f4.camel%40gmail.com.