Level 7

Solved

Managing the Access token for a Server to Server Configuration

Forum|Forum|1 year ago
February 22, 2024
5 replies
3465 views

Hello Team,

Recently I am working on a POC task, where I need to get details from Adobe Analytics and show the details in my AEM applications home page. So, basically this is a serer to sever connection, where I am displaying application specific data in my application. Consider: I am trying to get the most visited pages, and displaying in descending order based on visitor count.

Based on few articles, I was able to crack the logic to display the Adobe analytics data.

https://developer.adobe.com/developer-console/docs/guides/authentication/ServerToServerAuthentication/

https://adobedocs.github.io/analytics-2.0-apis/

https://developer.adobe.com/analytics-apis/docs/2.0/guides/endpoints/reports/

From this, I am able to get the access token too.

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/generate-server-to-server-authentication-access-token-from-java/td-p/654917 Special thanks to @imran__khan for his quick help.

From above I was able to get the response: Response {"access_token":"eyJhbSomeLetters","token_type":"bearer","expires_in":86399} Whether I will get refresh token here??? Not sure. Let me explore.

Now, my major query is: Ideally I should not save this access token in user browser cookie. Since, I need to use a single access token for all the end user request, until the token expires. How can I implement this logic?

I hope for every application to application integration (i mean AEM to Adobe Analytics or any other AEM app integration), concept of using the access token (which is specific to application)remains the same. So, I am curious to know from others, how you are managing to keep the access token in server? Note: My AEM application has 3 publisher environment.

Also, one more observation: What is this article? Related to Integration with Adobe Analytics using IMS

https://experienceleague.adobe.com/docs/experience-manager-65/content/sites/administering/integration/integration-analytics-ims.html?lang=en#:~:text=The%20integration%20of%20AEM%20with,the%20API%20supports%20IMS%20authentication.

cc @imran__khan @kautuk_sahni @aanchal-sikka @joerghoh @briankasingli @raja_reddy @estebanbustamante @arunpatidar @lukasz-m

Best answer by Imran__Khan

Hi @aanchal-sikka

I have checked the article. In that article, they are explaining about encrypting, decrypting the texts: client id, secret . also, to make sure these are proper in all the publisher environment. So, developer knows these values before the deployment(ie before run time). So that they can keep the encrypted keys in configuration files. This scenario is valid in my case, provided Application specific access key is same/valid for, just consider 1 year (Just a hypothetical case). But in my case, access key is like: Dynamic value. I mean need to change access token for every 24 hours. So, I cannot use the steps that is mentioned in the given article.

So, the only steps I can think of is: as mentioned by @imran__khan

"Save this access token somewhere in AEM crx/de and create service user having very specific access to fetch access and refresh token from crx/de node. Replace tokens every time you get new one."

So, in this case, I need to pass the same access token to remaining publish environments. How can I achieve this?

-Thanks

cc @imran__khan @kautuk_sahni @arunpatidar

@mahesh_gunaje Please user Sling Content Distribution(to publish content to different ) or Sticky session to have a publish and dispatcher one to one mapping and maintain publish specific access token.

Imran__Khan

Community Advisor

@Mahesh_Gunaje You will be getting access and refresh token. Access token to make subsequent calls until it is expired. Get new access token with the help of refresh token.

Save this access token somewhere in AEM crx/de and create service user having very specific access to fetch access and refresh token from crx/de node. Replace tokens every time you get new one.

aanchal-sikka

Community Advisor

@mahesh_gunaje

Since its a server-to-server communication, so there is no need to save this token in Browser.

Prefer to save it in CRX /var nodes, but encrypted.

Please find the encryption APIs here: https://www.tothenew.com/blog/aem-encryption-service-what-how-why/

Also, use the refresh token mechanism as suggested by @imran__khan

Aanchal Sikka

M

Mahesh_GunajeAuthor

Level 7

Thanks @aanchal-sikka @imran__khan for your help. I have checked the article: https://www.tothenew.com/blog/aem-encryption-service-what-how-why/

This looks good. But query is, using this, I can save the client id, client secret in an encrypted way in configuration file. That is fine. But in the case of Access token, This will be generated at the run time. Suppose, Just imagine, once this feature is moved to the production, for the 1st user request,(this request went to prod Pub1 instance) generated access token. Then, using service user I have saved this details in crx /var node. Then, I need to pass/use the same access token in other prod publish environment? So, need to use reverse replication?

Or else, I need to use sling scheduler concept? Since token expiration time is 24 hours. So, call Sling scheduler for every day ( or 2 times per day, just for the safer side) from prod author. get access toke, refresh token. Save it in crx /var in an encrypted way. Replicate to prod publisher environments??

I am happy to clarify all your doubts

cc @Imran__Khan @kautuk_sahni @Jörg_Hoh @BrianKasingli @RajaReddy_3370 @EstebanBustamante @arunpatidar @lukasz-m

Imran__Khan

Community Advisor

In this case author will not be there in picture. It all about publishers and sync data between publish instances. I would suggest to implement sticky session which will make sure to call s
https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/aem-dispatcher-sticky-session-with-multiple-publishers/m-p/211948

Imran__Khan

Community Advisor

@Mahesh_Gunaje You will be getting an access token in response. Use access token to make subsequent calls until it is expired. Every time get new access token once it is expired.

As suggested by @aanchal-sikka, save encrypted access token under AEM crx/de /var/project/token node and create service user having very specific access to fetch access token from crx/de node. Replace tokens every time you get new one.

You can use below sample code to generate access token.

import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.SecretKeySpec;;

import java.util.*;

public class TokenEncryptionDecryption {

    static byte[] encode;

    private static final String ALGORITHM = "AES";

    private static final String SUN_JCE = "SunJCE";

    private static final String ALGO = "AES/GCM/NoPadding";

    /* START AEM encryption */
    public static SecretKey generateSecretKey() throws Exception {
        KeyGenerator keyGenerator = KeyGenerator.getInstance(ALGORITHM);
        keyGenerator.init(256);
        return keyGenerator.generateKey();
    }

    /* Start encryption */
    public static String encrypt(String plaintext, SecretKey secretKey) throws Exception {
        Cipher cipher = Cipher.getInstance(ALGO);

        byte[] iv = new byte[12];
        Cipher.getInstance(ALGO, SUN_JCE);
        GCMParameterSpec spec = new GCMParameterSpec(128, iv);

        cipher.init(Cipher.ENCRYPT_MODE, secretKey,spec);

        byte[] encryptedBytes = cipher.doFinal(plaintext.getBytes());
        return Base64.getEncoder().encodeToString(encryptedBytes);
    }
    /* END encryption */

    /* Start decryption */
    public static String decrypt(String encryptedText, byte[] encode) throws Exception {

        SecretKey secretKey = new SecretKeySpec(encode, 0, encode.length, ALGORITHM);
        Cipher cipher = Cipher.getInstance(ALGO, SUN_JCE);
        byte[] iv = new byte[12];
        GCMParameterSpec spec = new GCMParameterSpec(128, iv);
        cipher.init(Cipher.DECRYPT_MODE, secretKey, spec);

        byte[] encryptedBytes = Base64.getDecoder().decode(encryptedText);
        byte[] decryptedBytes = cipher.doFinal(encryptedBytes);

        return new String(decryptedBytes);
    }
    /* End decryption */

    public static void main(String[] args) throws Exception {

        // Generate a secret key (or you can use a pre-shared key)
        SecretKey secretKey = generateSecretKey();
        encode = secretKey.getEncoded();

        // Save this also in CRX/DE
        String encoded = Base64.getEncoder().encodeToString(encode);

        String clientId = "MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3";
        System.out.println("clientId: " + clientId);

        String encryptedClientId = encrypt(clientId, secretKey);
        System.out.println("Encrypted Client ID: "+encryptedClientId);

        // Get from crx/de and decode back in to Byte array.
        encode = Base64.getDecoder().decode(encoded);
        String decryptedText = decrypt(encryptedClientId, encode);
        System.out.println("Decrypted Text: " + decryptedText);

    }
}

P

PiyushMi1

New Member

@mahesh_gunaje - you can keep/save multiple access token on all different Publisher P1, P2 (agreed token will be different and they are their own lifecycle and valid for 24hr). While request will come from LB, it could get connect on anyone of Publisher P1, P2, utilize the existing saved token for doing connection and fetch the results. Once access token will get expire then generate and save it again.

H

HarikrishnanBK

Hi @mahesh_gunaje Did you get a solution for this. I am having a use-case identical to you, in which i am confused on where to store the access token till it expires and also how to validate whether it expired or not.

Because in the token response it is just showing that it expires in 86399 (which is 24 hours in seconds).

Or the worst case is it feasible to generate a new token for every api call?

Please give me more insights on this

Regards,
Hari

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded