Expand my Community achievements bar.

SOLVED

Sign In via Custom Identity Provider

Avatar

Level 1

Hey, I've got an HTML article that will use the new setAuthToken API to provide a custom authentication to the user, and I can call it with a authToken that is authorised on the entitlement to login the user from the article.

However, I'm having an issue setting up the Custom Identity Provider required for this API to work. I've configured the project settings to use a custom IdP, and created a page that will check the credentials and get an authToken back. Now went the user selects Sign In from the Account model a web view pops up with the IdP login page. Once the user logs in were do I redirect to pass the authToken back to the APP? I can see the https://es.publish.adobe.com/oauth2​ URL in the case of the Outh, but don't see any for the Custom Idp... Has this been setup yet?

Thanks in advance,

Alex

1 Accepted Solution

Avatar

Correct answer by
Level 2

Hi Alex,

In your Generic Identity Provider set up, the authentication URL should be the page you created to check the credentials. When this page is launched from the viewer, there are several query parameters that are passed along with it. This includes:

redirectUri: The generic authentication callback URI.

projectId: The application's project's ID.

appId: The ID of the viewer application.

appVersion: The version of the viewer application.

uuid: The identifier for the device.

Your page should parse the redirectUri out of the URL parameters, and redirect to it when your authentication is complete. When redirecting to this redirectUri, you can include the following information back to the application:

authToken: authToken of the user after successful login.

expiresIn: Optional duration in seconds before the authToken expires.

error: Error message after login failure. Either error or authToken must be specified but not both.

  Hope this helps.

Thanks,

Christine

View solution in original post

4 Replies

Avatar

Correct answer by
Level 2

Hi Alex,

In your Generic Identity Provider set up, the authentication URL should be the page you created to check the credentials. When this page is launched from the viewer, there are several query parameters that are passed along with it. This includes:

redirectUri: The generic authentication callback URI.

projectId: The application's project's ID.

appId: The ID of the viewer application.

appVersion: The version of the viewer application.

uuid: The identifier for the device.

Your page should parse the redirectUri out of the URL parameters, and redirect to it when your authentication is complete. When redirecting to this redirectUri, you can include the following information back to the application:

authToken: authToken of the user after successful login.

expiresIn: Optional duration in seconds before the authToken expires.

error: Error message after login failure. Either error or authToken must be specified but not both.

  Hope this helps.

Thanks,

Christine

Avatar

Level 1

Hi, Christine  - thanks a for your response. I can indeed see the query parameters in the URL. However now when I try to redirect to it including the authToken in the URL, the APP pops-up and error "An error occurred signing you in. Please try again later", If I look at the actual response I see this

Any input would be great.

Thanks again,

Alex

Avatar

Level 2

Hi Alex,

Can you please confirm that you have a generic identity provider set up to point to your custom login page? What device are you testing on, or is this on the web? In order for me to debug further, would you mind private messaging me your project id?

The generic identity provider requires cookies to create a user's authentication state. Is there any reason why cookies might be disabled?

Thanks,

Christine

Avatar

Level 1

Hi, Christine - I think you were right, this might have been related to the setup.

I'd been working against an Entitlement Server and Identity Provider that were hosted locally - I could access them from my device on the same network, but there aren't accessible externally - however when I switched to an external server we have everything seemed to run without problem. I guess the adobe servers were trying to hit the ES and timing out.

Thanks for your help with this!

Alex