Forum Discussion

Hari329's avatar
Hari329
Adept
10 years ago

Authentication process

Hi ,

 

I am working on web service call to Lithium for pulling the data and display on our sites. As part of this implementation ,the first call made is to get authenticated and obtain a valid token (valid only for 30 minutes) & second call by using token we received from lithium to pull the required data.

 

Could you please clarify below items to get better understanding the process and come up with best possible approach for pulling data from lithium ?

 

1. Is there any way to get authentication and keep the validated code more than 30 minutes ?

2. Is there any API/Process to get the authentication process completed once and subsequent request can be made with same token ?

3. We are trying to reduce number of calls to lithium to get authentication every time when ever page is loaded as the web service call need to be made from different pages to pull relevant data .

 

Thanks a lot for your support in advance!

 

  • PaoloT's avatar
    PaoloT
    Lithium Alumni (Retired)

    Hi Hari329

     

    welcome to the forum. In terms of authentication, you will need to manage expired tokens. You can either use the standard username/password authentication system with session token, or use the new OAuth 2.0 auth grant flow

     

     

    In OAuth 2.0 you still need to handle expired access tokens and refresh tokens (more info here)

     

    If you are looking into reducing the amount of calls made you should investigate if the Studio Endpoints are a viable alternative in your use case.

     

    I hope this is helpful,

    • Hari329's avatar
      Hari329
      Adept

      And also there are different ways to authenticate lithium community as per the provided link :

      OAuth 2.0
      API session keys
      SSO
      Cookie-based authentication
      Auto-login cookies
      Permissions
      Privacy

       

      I have looked in to option of API session keys , in which we can have valid session key for 30 minutes. Could you please let me know in any one of other methods available above can provide longer validity of the authentication so that we don’t need to call lithium multiple times regularly for authentication ?

      Thanks,

      Hari

      • PaoloT's avatar
        PaoloT
        Lithium Alumni (Retired)

        Hi Hari329

         

        The OAuth authorization grant flow is more recommended for an interactive user. Therefore, if you instead require to perform backend "P2P" calls it may be more appropriate to use the user/password and session key mechanism.

         

        The expiration time of the session key is defaulted to 30 minutes. I think this can be changed from the configuration (this should be checked with Support) however I do not reccomend this as it would go against its purpose. Ultimately, it is intended behavior that the token has a limited timespan: therefore your integration code should handle expired tokens and obtaining new ones in the expected scenarios.

         

        The expiration time is for inactive sessions, so as long as you keep making calls within this time limit, it will not expire to my knowledge (as the timer will be re-set because of the activity)

         

        Kind Regards,

    • Hari329's avatar
      Hari329
      Adept

      Hi Paolo,

      Thanks for the input.

      Please correct me if I my understanding is not correct - as per OAuth 2.0 authorization grant flow process , user will be taken to log in page first time to enter credentials and then lithium authenticates request based on credentials & accept same authenticated access token for next 24 hours.

      Is there any way we can pass these credentials programmatically so that it won’t ask end user to enter credentials ?

      In our requirement , we are going to call our lithium community site for pulling data and display to customer. We can’t redirect to log in screen of lithium for the first time for the authentication process.

      Please correct me if my understanding is not correct.

      Thanks,

      Hari