Skip to main content
Known Participant
May 12, 2023
Answered

Baffled. Did Abobe encourage me to switch to OAuth before the were ready?

  • May 12, 2023
  • 1 reply
  • 3252 views

Hi all.

 

I just signed up to test/use PDF Services. The system set up my new dev account with some JWT credentials with big warnings that everything it just set up for me was instatly deprecated and should be migrated. Well, that's just Adobe (from my years of experience with them) I thought, and carried on.

 

I tested a .net htmlToPdf doc generation (using the sample code in the .net SDK), which seemed to work - but then thought I should listen to the big red warnings and follow Adobe's advice about upgrading/migrating.

 

The problem is, it now seems that there are no relevant samples, no documentation and no .net SDK support for using the API with the new pattern. Are all the .net SDK samples pointing to an old api that is deprecated? Did Adobe just point me towards a migration into a world where there is no support or documentation or any way of knowing how to use it yet?

 

Hopefully I'm missing the obvious here.... but baffled.

Adobe being Adobe again or just a daft user bafflement?

This topic has been closed for replies.
Correct answer Raymond Camden

You are absolutely right. The messaging here could have been better. I have a blog post coming out ASAP on this, but it may be a day or two before published. Let me TLDR it:

 

1) Yes, there is a new auth schema, but your current auth (JWT) will work till January 1, 2025.

2) The SDKs for our stuff, and most APIs here at Adobe, have not yet been updated to use the new auth. So the "old" JWT auth is what you would use.

3) The REST APIs, however, can use either.

 

So for right now, if you are a SDK user, sit tight. Ignore the scary warnings in the console, and note that our SDKs/docs will be updated soon.

 

If you are a REST user, and would like to use the new stuff, I'm happy to share code demonstrating how it works. The good news is that it's a heck of a lot simpler. 

1 reply

Raymond Camden
Community Manager
Raymond CamdenCommunity ManagerCorrect answer
Community Manager
May 12, 2023

You are absolutely right. The messaging here could have been better. I have a blog post coming out ASAP on this, but it may be a day or two before published. Let me TLDR it:

 

1) Yes, there is a new auth schema, but your current auth (JWT) will work till January 1, 2025.

2) The SDKs for our stuff, and most APIs here at Adobe, have not yet been updated to use the new auth. So the "old" JWT auth is what you would use.

3) The REST APIs, however, can use either.

 

So for right now, if you are a SDK user, sit tight. Ignore the scary warnings in the console, and note that our SDKs/docs will be updated soon.

 

If you are a REST user, and would like to use the new stuff, I'm happy to share code demonstrating how it works. The good news is that it's a heck of a lot simpler. 

DebuggleAuthor
Known Participant
May 12, 2023

Thank you for taking the time to reply Raymond - it really is appreciated by us all. Where's the blog post coming out? I'd love to read it when done.

 

If you have any code to share about the new stuff that would be great. I'm an asp.net core developer looking to get simple htmlToPdf things under way for starters - which I understand could be quite a tricky multi-step process using the REST tools - so keen to get any insight and get stuck in. So, .net code preferred but I'll take anything! 😉

 

It's difficult to know how far we'll go with the services because we're finding quite a lot of resistance from Adobe when it comes to pricing - but I assume they will get back to us eventually with an idea of how pricing tiers work (and importantly what the tiers are).

 

Really hoping this is a service being made available to regular folks and more than just the Microsoft's of the world. Could all be very exciting!

Participating Frequently
May 17, 2023

The code for this blog post isn't in a GitHub repo (when I get a sample using our APIs I'll have some), but here's the gist.

 

Here is a function I'd use to generate an access token. It does this by making a JWT, and hitting an endpoint to convert it to an access token. Here's the function:

async function getAccessToken(config) {

	let scope = `https://ims-na1.adobelogin.com/s/${config.metaScopes}`;
	let cred = {
		"iss":config.orgId, 
		"sub":config.technicalAccountId,
		"aud":`https://ims-na1.adobelogin.com/c/${config.clientId}`
	};

	cred[scope] = true;

	const token = sign(cred, config.privateKey, {expiresIn: 300, algorithm: 'RS256'});

	let body = `client_id=${config.clientId}&client_secret=${config.clientSecret}&jwt_token=${token}`;
    let getATReq = await fetch('https://ims-na1.adobelogin.com/ims/exchange/jwt', {
      method:'POST', 
      headers: {
        'Content-Type':' application/x-www-form-urlencoded'
      },
      body: body
    });
    
    return await getATReq.json();

}

And here's how I call it. The capitalized variables are my credentials, each named (hopefully) in a way that makes sense:

let config = {
	clientId: CLIENT_ID,
	clientSecret: CLIENT_SECRET, 
	technicalAccountId: TECHNICAL_ACCOUNT_ID,
	orgId: ORG_ID,
	privateKey: KEY,
	metaScopes:'ent_ccas_sdk'
}

let { access_token } = await getAccessToken(config);

 

Once you have the access token, you can then go to town.

 

In the new system, you will ONLY use a client id and client secret. So for example:

let access_token = await getAccessToken(CLIENT_ID, CLIENT_SECRET);

And here's the updated function:

async function getAccessToken(clientId, clientSecret) {

	const params = new URLSearchParams();
	params.append('client_secret', clientSecret);
	params.append('grant_type', 'client_credentials');
	params.append('scope', 'openid,AdobeID,read_organizations');

	let resp = await fetch(`https://ims-na1.adobelogin.com/ims/token/v2?client_id=${clientId}`, 
		{ 
			method: 'POST', 
			body: params
		}
	);
	let data = await resp.json();
	return data.access_token;
}

 

Hope this helps!


Will this endpoint work with eSign too?  It appears that the the Integration Key has been removed, but the OAuth enpoints used for sign give a "Invalid grant_type client_credentials" when trying to use the client_credentials flow.