I'm currently working on a way to hand off creation of users in a Userpool to my product team so that I don't need to handle user creation and password resets anymore. The key here is that the tool I give them needs to be simple and non-technical, and not require them going into was with permissions, knowing how to use Cognito and make the users within Cognito. This also needs to not be a public facing signup (i.e. the folks using the page need to never see the signup form). This is for my team's developer documentation which integration partners cannot see until they meet with us.
Looking at all the possibilities and the AWS API documentation has been making my head spin, though. I'm not sure what the best way to create this tool - the Cognito SDK? The AWS AdminCreateUser API? Or is there a way to set this up with the built in signup page UI provided by Cognito but host the signup page elsewhere (somewhere that people who look at our documentation will never see a signup page)?
Please let me know what your approach would be if given this problem. I'm a pretty green jr. developer and don't have much experience with AWS.
If you really don't want to use the built-in Cognito UI to create users, you would need to come up with an alternative custom solution. Mind you will need to implement all features you expect from such user administration tool, including login for administrators into the tool itself.
With AWS Cognito APIs you can do everything native UI can do (and even more, like setting user attributes which is not available at Cognito console).
Quick google search led me to this project: https://github.com/jzoric/cognito-user-manager-ui which may be a good starting point if you decide to go this route.
Alternatively you may want to explore other SAAS solutions (Auth0 or Okta) which may provide better native UI out of the box.
Related
https://consumerdatastandardsaustralia.github.io/standards/#security-profile
I am trying to setup AWS Cognito as an OIDC provider. Able to create User pool however there are lots of custom data needed. Such as ".well-known/openid-configuration" of Cognito returns few details but missing introspection_endpoint, revocation_endpoint, claims_supported etc.
Similary, customization of /authorize endpoint with additional claims is needed.
Any help or suggestions would be really helpful.
Regards & Thanks
Claims can be somewhat customised with a lambda: https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html
introspection_endpoint and revocation_endpoint are not core oauth and are extensions. I have found Cognito does not generally implement extensions, there are many parts of oauth2 core not implemented also.
Cognito is missing many many features you may expect to get out of the box, there is a seemingly large and opaque backlog which support constantly reference when you point out that a standard feature is missing.
no silent refresh capability in the hosted UI, so no safe way to store the refresh token.
no support for custom auth flow in the hosted UI
no passwordless support in the hosted UI
no ability to pre-populate a field in the hosted UI (e.g. username)
no ability to customise the plethora of obscure error messages in the custom UI
fixed now, but for years the email addresses were case sensitive!
If you choose not to use the hosted UI there is no way to get any oauth scopes.
There are many non-oauth cognito idp calls that you may be able to use with the access token: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cognito-idp/index.html
If these don't fit your needs, I would suggest you consider other auth services, or adjust your expectations if you choose to move forward with Cognito. Good luck!
I want to use AWS services into my app for authentication and basic functionalities which include : Login, Register, Forgot Password, Change Password, Delete account, etc.
I have searched a lot and found that there are many ways :
By using Amplify Framework
AWS Mobile client
By Amazon Cognito
By Identity Provider
Actually, I am little confused, what is the difference between all these ? Which one is the best way to implement ? And while go for documentation, there are so many official documentation about it on google. Which can be consider ?
https://github.com/awslabs/aws-sdk-ios-samples/tree/master/CognitoYourUserPools-Sample/Swift
https://aws-amplify.github.io/aws-sdk-ios/docs/reference/AWSMobileClient/index.html
https://aws-amplify.github.io/aws-sdk-ios/docs/reference/AWSCognito/index.html
https://aws-amplify.github.io/aws-sdk-ios/docs/reference/AWSAuthCore/index.html
https://aws-amplify.github.io/aws-sdk-ios/docs/reference/AWSCognitoAuth/index.html
What are all these use for ? Can anyone differentiate ?
these are all abstractions on top of the lower level generated Cognito Client designed to make it easier on the developer to call Cognito API's. The lowest level ones are AWSCognito, AWSAuthCore, and AWSCognitoAuth. The AWSMobileClient is a higher level abstraction built on top of all of these to make it easier to hit the Cognito API's in a way most developers can understand (Cognito can be fairly complex) and is the one the Mobile SDK teams here at AWS recommend using. Amplify will have an Auth category which will be an even higher level abstraction and will also be generic to any auth provider when it is done but right now it's still in progress( you can track PR's for the Auth category here and here) thus Amplify is depending on the AWSMobileClient for auth at the moment.
I'm looking for the right approach to solve the following problem:
For my own non-business Instagram account I like to read which accounts follow me and which accounts like and comment my posts.
I read about the old and the new API, about API deprecation etc. Now I'm unsure which approach shall I choose?
Instagram Platform API
Graph API
other approach like browser automation (e.g. InstaPy)
Instagram/Facebook says "If you are building apps for Instagram Non-Business Accounts, please use the Instagram Platform API". But the process to get an account seams to be complicated. And as I understand until 2020 Instagram will deprecate this API completely.
Additionally as I understand the sandbox mode doesn't help me, since it is restricted and won't show the real results.
From what I can tell, you should use the Instagram Platform API. I think you're right that the Graph API is only for servicing Business Accounts.
I'm in the same boat. I made an app that lets users sign in with their own non-business accounts. Setup OAuth flow using the old API, which works in sandbox.
However, I submitted for approval this week and haven't heard anything. There's no way to contact Instagram or know how long it will take to get approved.
I personally have some experience with InstaPy and I can tell you that it is used mainly for directly interacting with said accounts. You can follow, comment, like, etc... on these accounts that follow you but actually accessing a list of all of them would be more tricky. That's why I wouldn't recommend browser automation for the goal you have set out for.
My team is trying to develop a product for the google apps marketplace and I am having issues with the workflow in the new ADMIN SDK.
With the now deprecated Provisioning API we simply ask for a username and password from the account we are trying to manage.
With the ADMIN SDK it seems as though they would need to go enable the API, create a key and do a lot of manual work for this to happen. This really is a tough option for us as the technical level of our clients is not likely to be able to make this transition.
Is there something like the work flow for the provisioning API where they can enable management from a third party or a recommended workflow for a developer to build an application that can access any number of google apps accounts?
A use case for this is say I want to develop a different option for a console, I want to build a console web app and simply ask for credentials or easy setup routine and allow our users to manage their google apps account in a different way.
Thanks in advance,
Steve
The Admin SDK Directory and Reports APIs work correctly with 2-legged OAuth 1.0a which is what the Google Apps Marketplace currently supports and automates. You do need to turn the Admin SDK on under "Register for additional APIs" from your Vendor Profile page on the marketplace. Also, the Administrative APIs for the domain must be turned on. You'll get a generic error that the domain cannot use the APIs if it's off in which case you can direct the client to the exact CPanel page where they can turn it on.
I am trying to build an application that will use data from multiple social services. The user will need to authorize their accounts to be accessed across these multiple services (e.g. facebook, twitter, foursquare) using oauth.
I don't really need the users to login with these accounts, really it is just allowing their data from the api to be pulled.
I know I need to use oauth, but I am having trouble finding a basic example of how to do this type of thing (a lot of examples exist for logging in with oauth).
I have been trying the python-oath2 library.
Does anyone have any recommendation for a good tutorial or example of doing this type of thing in python, and if possible django.
Thanks.
Why reinvent the wheel? There is a plethora of reusable applications that have this implemented. You can find a comparison here: http://djangopackages.com/grids/g/authentication/
Why not give rauth a try? We use this in production for this exact purpose. Although you don't need to require the user to login with your app via the provider, you're going to redirect to the provider, where they'll be asked to authenticate your application. Assuming they accept (or even if they don't), they'll be redirected back to your application, i.e. via the redirect_uri or oauth_callback, there you'll ensure they authorized your app and then proceed with whatever housekeeping you need to do, e.g. saving some info about the user in your database. Try the examples and also pay particular attention to the Facebook example. Now the Facebook example is intended for authorization with the example web app, but the same pattern can be used for what you're trying to do. (You just won't be having them login in via Facebook, for instance. However, the flow can be and probably should be identical, sans database operations and template login lingo.)