Python social auth apple

Implementing Sign In with Apple in your Django (Python) backend

Nov 28, 2019 · 4 min read

Apple has launched a new feature, “ Sign In with Apple” which is secure and maintain the privacy of their users. Apple is making sure that this feature enables users to sign in to apps using their traditional Apple ID. Users can decide whether they want to share their email to the apps or not. Apple will generate a proxy email address unique to each app and then all the communication between the user and the app will be done through that proxy email address.

How it works

The authenticati o n part of the new API is built on top of the existing standards OAuth 2.0 and OpenID Connect. If you’re familiar with these technologies, you can easily start implementing Sign in with Apple.

Python Social Auth

In this article, we’ll be using Python Social Auth as it provides OAuth 2.0 and OpenID support. We’ll be adding a new custom backend.

Generating the private key

Before you start diving into the code, you’ll need to generate a key on Apple’s Developer Portal in order for Apple to associate and verify your requests.

Request to the Apple ID service

Once the iOS app calls the backend with an authorizationCode , you can make your authentication request. It consists of a few pieces:

• Key ID (The ID of the key you’ve generated on Apple’s Developer Portal)
• Apple Developer Team ID
• Client ID (The iOS app’s bundle ID, e.g. com.yourcompany.yourapp )
• Client Secret

Creating the Client Secret

Apple requires you to derive a client secret from the private key every time. They use the ES256 JWT algorithm to generate that secret. This is also described in Apple’s documentation Creating the Client Secret.

We have used PyJWT to generate the client secret.

Implementing a custom backend

Now that you can make authenticated requests, you can start with the custom backend. Python Social Auth implements the OAuth 2.0 standard but Apple has some differences in their flow. In order to complete Sign In with Apple you have to extend BaseOAuth2 and customise or override some functions.

• get_key_and_secret override this as you have to generate the client secret the way mentioned above
• get_user_details override just to give the email address or other user information back to the Python Social Auth framework
• do_auth override this method as you need to verify the code or access token given by mobile client from apple and get the ID token from which other details can be extracted.

What is so important about the ID Token?

With the response of the validate token call, Apple returns an id_token that contains bunch of information. Two things are very important: sub (subject) is the unique user id and email is the email address of the user, obfuscated or real.

You can decode the token by using JWT like:

You can also refer to Apple’s documentation Generate and Validate Tokens that explains this.

We have created the AppleOAuth2 class as a custom backend doing Sign In with Apple using Python Social Auth.

A very important thing to know is, that the email address and the name are returned only the first time you make the request. So, if you need to test this over and over again, you need to remove your app from the authorized apps of your AppleID account everytime.

Not using Python Social Auth?

If you are not using Python Social Auth, you can manually create the user after the validation of the user and decoding of the id_token you got from Apple. In case the uid already exists, then that’s the same user, you just have to login. In our case Python Social Auth is doing this already 🙂

Who we are?

Beginning this fall, Apple requires iOS apps to feature the “Apple way” of logging into or signing up for apps, that provide other means of social signup. Here at truffls, Lukas Wuerzburger (on the iOS app side) an I, Aamish Baloch (on the backend side) developed this functionality.

Since we could only find small amounts of information on the app side online, we wanted to help others struggle less with this. We hope you enjoyed this article and it helps you. 🙂

You can also find iOS guide and the complete code here.

I would also like to thank Aaron Parecki for writing an amazing article “What the Heck is Sign In with Apple?” that helped me a lot. Cheers!

Источник

social-auth-core 4.1.0

pip install social-auth-core Copy PIP instructions

Released: Mar 5, 2021

Python social authentication made simple.

Navigation

Project links

Statistics

View statistics for this project via Libraries.io, or by using our public dataset on Google BigQuery

License: BSD License (BSD)

Tags openid, oauth, saml, social auth

Requires: Python >=3.6

Maintainers

Classifiers

• Development Status
  • 4 — Beta
• Environment
  • Web Environment
• Intended Audience
  • Developers
• License
  • OSI Approved :: BSD License
• Programming Language
  • Python
  • Python :: 3
  • Python :: 3.6
  • Python :: 3.7
  • Python :: 3.8
  • Python :: 3.9
• Topic
  • Internet

Project description

THIS PROJECT IS OPEN FOR MAINTAINERS

Development on the ptyhon-social-auth projects has been stagnated for a while, #445 was open a long time ago to discuss this matter and a plan (failed) was presented to fix the situation. For that reason, I’m opening the organization to new maintainers that will have the proper permissions to unstuck development.

Those willing to join, contact me by email with the subject [PSA Maintainer] and please let me know what motivates you to join in such role.

Python Social Auth — Core

Python Social Auth is an easy to setup social authentication/registration mechanism with support for several frameworks and auth providers.

Description

This is the core component of the python-social-auth ecosystem, it implements the common interface to define new authentication backends to third parties services, implement integrations with web frameworks and storage solutions.

Источник

Configuration¶

Application setup¶

Once the application is installed (check Installation) define the following settings to enable the application behavior. Also check the sections dedicated to each framework for detailed instructions.

Settings name¶

Almost all settings are prefixed with SOCIAL_AUTH_ , there are some exceptions for Django framework like AUTHENTICATION_BACKENDS .

All settings can be defined per-backend by adding the backend name to the setting name, like SOCIAL_AUTH_TWITTER_LOGIN_URL . Settings discovery is done by reducing the name starting with the backend setting, then the app setting, and finally the global setting, for example:

The backend name is generated from the name attribute from the backend class by uppercasing it and replacing — with _ .

Keys and secrets¶

Set up needed OAuth keys (see OAuth section for details):

OpenID backends don’t require keys usually, but some need some API Key to call any API on the provider. Check Backends sections for details.

Authentication backends¶

Register the backends you plan to use, on Django framework use the usual AUTHENTICATION_BACKENDS settings, for others, define SOCIAL_AUTH_AUTHENTICATION_BACKENDS :

URLs options¶

These URLs are used on different steps of the auth process, some for successful results and others for error situations.

Used to redirect the user once the auth process ended successfully. The value of ?next=/foo is used if it was present

URL where the user will be redirected in case of an error

Is used as a fallback for LOGIN_ERROR_URL

Used to redirect new registered users, will be used in place of SOCIAL_AUTH_LOGIN_REDIRECT_URL if defined. Note that ?next=/foo is appended if present, if you want new users to go to next, you’ll need to do it yourself.

Like SOCIAL_AUTH_NEW_USER_REDIRECT_URL but for new associated accounts (user is already logged in). Used in place of SOCIAL_AUTH_LOGIN_REDIRECT_URL

The user will be redirected to this URL when a social account is disconnected

Inactive users can be redirected to this URL when trying to authenticate.

Successful URLs will default to SOCIAL_AUTH_LOGIN_URL while error URLs will fallback to SOCIAL_AUTH_LOGIN_ERROR_URL .

User model¶

UserSocialAuth instances keep a reference to the User model of your project, since this is not known, the User model must be configured by a setting:

User model must have a username and email field, these are required.

Also an is_authenticated and is_active boolean flags are recommended, these can be methods if necessary (must return True or False ). If the model lacks them a True value is assumed.

Tweaking some fields length¶

Some databases impose limitations on index columns (like MySQL InnoDB). These limitations won’t play nice on some UserSocialAuth fields. To avoid such errors, define some of the following settings.

Used to define the max length of the field uid . A value of 223 should work when using MySQL InnoDB which impose a 767 bytes limit (assuming UTF-8 encoding).

Nonce model has a unique constraint over (‘server_url’, ‘timestamp’, ‘salt’) , salt has a max length of 40, so server_url length must be tweaked using this setting.

SOCIAL_AUTH_ASSOCIATION_SERVER_URL_LENGTH = or SOCIAL_AUTH_ASSOCIATION_HANDLE_LENGTH =

Association model has a unique constraint over (‘server_url’, ‘handle’) , both fields lengths can be tweaked by these settings.

Username generation¶

Some providers return a username, others just an ID or email or first and last names. The application tries to build a meaningful username when possible but defaults to generating one if needed.

A UUID is appended to usernames in case of collisions. Here are some settings to control username generation.

This controls the length of the UUID appended to usernames.

If you want to use the full email address as the username , define this setting.

For those that prefer slugged usernames, the get_username pipeline can apply a slug transformation (code borrowed from Django project) by defining this setting to True . The feature is disabled by default to not force this option to all projects.

By default a set of regular expressions are applied over usernames to clean them from usual undesired characters like spaces. Set this setting to False to disable this behavior.

Sometimes extra cleaning up of usernames is needed in order to fit properly in a project, this setting is used to point to a function that will be called with the current username value, the output will be used as the new username. This method can be called multiple times in case of a collision. The setting value must be in the format of an import path.

Extra arguments on auth processes¶

Some providers accept particular GET parameters that produce different results during the auth process, usually used to show different dialog types (mobile version, etc).

You can send extra parameters on auth process by defining settings per backend, example to request Facebook to show Mobile authorization page, define:

For other providers, just define settings in the form:

Also, you can send extra parameters on request token process by defining settings in the same way explained above but with this other suffix:

Basic information is requested to the different providers in order to create a coherent user instance (with first and last name, email and full name), this could be too intrusive for some sites that want to ask users the minimum data possible. It’s possible to override the default values requested by defining any of the following settings, for Open Id providers:

For OAuth backends:

Processing redirects and urlopen¶

The application issues several redirects and API calls. The following settings allow some tweaks to the behavior of these.

The auth process finishes with a redirect, by default it’s done to the value of SOCIAL_AUTH_LOGIN_REDIRECT_URL but can be overridden with next GET argument. If this setting is True , this application will vary the domain of the final URL and only redirect to it if it’s on the same domain.

SOCIAL_AUTH_ALLOWED_REDIRECT_HOSTS = [‘foo’, ‘bar’]

To allow redirection to certain domains while keeping the more restrictive SOCIAL_AUTH_SANITIZE_REDIRECTS = True setting. This will redirect to the next GET argument if the hostname is on the list, otherwise it defaults to the value of SOCIAL_AUTH_LOGIN_REDIRECT_URL .

On projects behind a reverse proxy that uses HTTPS, the redirect URIs can have the wrong schema ( http:// instead of https:// ) if the request lacks the appropriate headers, which might cause errors during the auth process. To force HTTPS in the final URIs set this setting to True

Any urllib2.urlopen call will be performed with the default timeout value, to change it without affecting the global socket timeout define this setting (the value specifies timeout seconds).

urllib2.urlopen uses socket.getdefaulttimeout() value by default, so setting socket.setdefaulttimeout(. ) will affect urlopen when this setting is not defined, otherwise this setting takes precedence. Also this might affect other places in Django.

timeout argument was introduced in python 2.6 according to urllib2 documentation

Whitelists¶

Registration can be limited to a set of users identified by their email address or domain name. To white-list just set any of these settings:

SOCIAL_AUTH_ _WHITELISTED_DOMAINS = [‘foo.com’, ‘bar.com’]

Supply a list of domain names to be white-listed. Any user with an email address on any of the allowed domains will login successfully, otherwise AuthForbidden is raised.

SOCIAL_AUTH_ _WHITELISTED_EMAILS = [‘me@foo.com’, ‘you@bar.com’]

Supply a list of email addresses to be white-listed. Any user with an email address in this list will login successfully, otherwise AuthForbidden is raised.

Miscellaneous settings¶

During the pipeline process a dict named details will be populated with the needed values to create the user instance, but it’s also used to update the user instance. Any value in it will be checked as an attribute in the user instance (first by doing hasattr(user, name) ). Usually there are attributes that cannot be updated (like username , id , email , etc.), those fields need to be protect. Set any field name that requires protection in this setting, and it won’t be updated.

Set any field name that requires protection in this setting, and it won’t be updated after inital population. This setting is similar to SOCIAL_AUTH_PROTECTED_USER_FIELDS in that they both do not allow changes of the data — however this one allows it to be set if no prior value exists. An example use case might be an application that seeds data from a social plaform but allows the users to override it locally.

By default, user session expiration time will be set by your web framework (in Django, for example, it is set with SESSION_COOKIE_AGE). Some providers return the time that the access token will live, which is stored in UserSocialAuth.extra_data under the key expires . Changing this setting to True will override your web framework’s session length setting and set user session lengths to match the expires value from the auth provider.

Enable OpenID PAPE extension support by defining this setting.

If you want to store extra parameters from POST or GET in session, like it was made for next parameter, define this setting with the parameter names.

In this case foo field’s value will be stored when user follows this link href=»<% url socialauth_begin 'github' %>?foo=bar»>. .

When this setting is True and social_core.pipeline.mail.send_validation is enabled, it allows the implementation of a passwordless authentication mechanism. Example of this implementation can be found at psa-passwordless.

Define the User-Agent header value sent to on every request done to the service provider, used when combined with a backend that sets the SEND_USER_AGENT property to True . Default value is the string social-auth- .

Account disconnection¶

Disconnect is an side-effect operation and should be done by POST method only, some CSRF protection is encouraged (and enforced on Django app). Ensure that any call to /disconnect/ / or /disconnect/ / / is done using POST.

When disconnecting an account, it is recommended to trigger a token revoke action in the authentication provider, that way we inform it that the token won’t be used anymore and can be disposed. By default the action is not triggered because it’s not a common option on every provider, and tokens should be disposed automatically after a short time.

Источник