I'm working on a custom skill which should allow account linking with a platform using Keycloak. Implicit Grant flow works fine, when switching to Authorization Code flow, it's not. From Alexa docs (https://developer.amazon.com/en-US/docs/alexa/account-linking/configure-authorization-code-grant.html#tokens), I understand that on access-token request Alexa does not send the redirect_uri, which is mandatory (according to RFC 6749, the standard that Amazon claims it follows) and also Keycloak enforces to use it (request fails without it). Did anyone else had this issue? Is there any workaround in Keycloak to overcome this constraint?
Related
I'm part of a small team as a nodeJS dev and I've been tasked into researching how this can be accomplished. I'm fairly new to OAuth and authentication so please bear with me.
Currently we have a next.js webapp that uses NextAuth for authentication with the user store in DynamoDB. What we want to do is provide an Oauth2 flow so a user can consent to a 3rd party service having access to their profile information via an endpoint. In this case we are the resource server, the 3rd party is the "client" and our user is the resource owner.
The piece of the puzzle I'm trying to put together is how does Auth0 work with NextAuth in this scenario? I want Auth0 to check if the user is logged in (otherwise prompting them to do so) via NextAuth, and for NextAuth to say "this is fine" and then for Auth0 to issue a token to the 3rd party (concluding a "normal" OAuth flow). Is this were SAML comes into play? I see there's a software package called SAML Jackson (lol) and there's a Next-auth integration for it.
Most examples I see usually work the other way around, with Auth0 as the identity provider, and what we're doing may be unique. Sorry if this question comes across as abstract but that's how it exists in my mind currently. Any help understanding this would be greatly appreciated.
You can connect your user store to Auth0 as a custom database connection. And then create an application inside Auth0 and enable the DB connection for the app. This way Auth0 acts as the Authorization server for your client app.
NextAuth.js is just an authentication library that supports the OAuth2.0/OpenID protocols. The role of NextAuth is simply to initiate the authentication flow, take the user to the Identity Provider (in this case Auth0 backed by a custom user store) and finally process the authorization response from Auth0. The authorization response (code) is received at the application end and then exchanged for access_token and user profile (all handled by NextAuth.js).
And for your query on SAML, it's a standard for exchanging identity information between two parties an Identity Provider (IdP) and a service provider (SP). The same is achieved by its more modern counterparts OAuth2.0/OpenID Connect. Typically third-party apps which are deployed in an enterprise setting use SAML to integrate with on-premise Identity Management Systems like ActiveDirectory. You can read more about SAML on https://boxyhq.com/blog/understanding-saml-sso-the-basics-from-the-user-side.
The architecture of the system is like this
User can log into the website using either username-password approach (after registration) or a google-sign-in.
I want to know how can I implement authentication and authorization for this scenario.
Here is what I am thinking of implementing :
Have an REST API server built over NodeJS and Express.
The login and registration processes are handled by this server as well.
The authentication is done by using JWT Tokens stored in the client side. And these tokens are then used again for authorization of endpoints as well.
How much secure is this approach? And how can google sign in be added to this architecture.
And also if a seperate server for making auth requests is needed as mentioned in OAuth 2.0?
It would be better if the system remains Stateless to follow the principles of RESTFul APIs.
This post that I have written might give you some insight.
https://dev.to/ralphwjz/login-management-for-spa-and-everyone-else-12o6
The post covers Github login but if you replace GitHub with google, the rest of the flow is exactly the same.
I can answer more questions once in context
How can I authenticate my mobile app(flutter) against social providers while using a flow provided by an IdentityServer4 system?
I'm trying to build a mobile app which will authenticate a user via Azure AD b2c. This question will be valid for any provider of an IdentityServer4 service though. For mobile apps, everything I read suggests using the Resource Owner Password Credentials(ROPC) flow. My understanding is that ROPC does not allow for social providers to be authenticated with. Is there an alternative flow to use specifically for social providers authentication? Is my understanding of ROPC wrong? I know mobile apps can authenticate with social providers, I've seen enough do it.
If you want to authenticate social providers and the users of mobile application, you could use auth code flow via Azure AD B2C. You can use it for authentication and authorization in most application types, including web applications and natively installed applications.
About Resource Owner Password Credentials (ROPC) flow, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks which are not present in other flows. You should only use this flow when other more secure flows can't be used. It is not recommended.
Update:
How does the auth code flow work for mobile authentication when it needs a redirect uri to send the resulting token to? This seems similar to the implicit flow for websites.
They are similar, but they apply different application types. You could learn more about the flow(auth code flow, implact flow). The docs are about AzureAD, but the processes are the same as B2C.
The protocol diagram of auth code flow is this:
The protocol diagram of implicit flow is this:
My company distributes an application with a background service component that sends and receives mail from a single email account using SMTP/POP3.
The app uses basic authentication, but we need to implement OAuth 2.0 now due to Microsoft's planned rollback of basic auth for POP3 (and likely SMTP in the future). We have been investigating the account setup and API permissions necessary to achieve this in Azure AD.
Our current understanding is that it is possible to implement the 2-legged client credentials flow by getting an access token and then sending requests to the Graph API (eg. https://graph.microsoft.com/Mail.ReadWrite). However, our application is built to send and receive with the legacy SMTP/POP3 protocols and changing the mail features to send HTTP requests to the Microsoft API endpoints requires a partial redesign.
It appears that only 3-legged flows are supported for the legacy SMTP and POP protocols. These permissions are only available as "delegated permissions" on the Graph API. There are no equivalent "application permissions" that would allow us to use these protocols from our background service without a user present to do the initial authentication.
Integrating a browser redirect into the app for the initial authentication also requires a significant update to the application. The app is 14 years old and the original programmer is no longer at the company. Due to that fact as well as limited resources, we're hoping for a solution that doesn't involve implementing browser integration or major changes to the sending and receiving functions.
Is it possible to implement a 2-legged OAuth flow to authenticate an account for sending and receiving over SMTP/POP3?
Might any of our assumptions be incorrect?
No. It's impossible.
OAuth access to IMAP, POP, SMTP AUTH protocols via OAuth2 client credentials grant flow is not supported.
Currently the supported flows are:
OAuth2 authorization code flow
OAuth2 Device authorization grant flow
See details here.
If you have this requirement, you can post your idea on Microsoft Graph user voice.
I am in a process to evaluate the capabilities of DocuSign by integrating with ServiceNow. If that works out well we are gonna take the licensing part forward for signup.
Link to ServiceNow Docs for using DocuSign Spoke of Integration Hub
DocuSign: https://developers.docusign.com/esign-rest-api/guides/building-integration
The issue here is : Steps given in the DocuSign documents and the relevant option isn’t present in DocuSign Sandboxed instance. Basically I am not able to get the Client ID and Client Secret.
I am not really sure of the significance of giving the Sandboxed instance if we can't do any integration.
Steps from Docusign
Snip from DocuSign Sandbox instance
Please provide any points on this integration and way forward to get it done.
Thanks.
You can do full dev integration with the Sandbox instance. First you need to know the Authentication Type to be used by your integration which you can read here. Once You know which Auth type to use, then you can either follow Auth Code Grant which will help you in creating IntegratorKey (aka ClientId), SecretKey and Redirect URI. But if you want to do JWT then you need to follow JWT Auth which will guide you in creating RSA Key Pair and Redirect URI.