The Meetup authentication works as follows:

1. Chapter-level authentication:
   1. The Meetup integration supports authenticating at the chapter level, where each chapter can have its own OAuth token stored in the ObjectMap.
   2. The chapter-level OAuth token includes an access_token and a refresh_token.
   3. The source code first checks if the chapter has a valid OAuth token stored in the extra_data field of the ObjectMap linked to the Meetup integration and the particular chapter. Example highlighted in purple:
      

      {
        "content_type": {
          "app_label": "chapters",
          "id": 9,
          "model": "chapter"
        },
        "created_date": "2024-11-01T15:29:43Z",
        "external_app": "meetup",
        "external_id": "malmo-atlassian-community-events",
        "extra_data": "{'oauth_token': {'access_token': 'eyJ0eXAiOiJK..', 'refresh_token': 'eyJ0eXAiO..', 'token_type': 'bearer', 'expires_in': 3600, 'expires_at': 1731092217.5969832}}",
        "id": 980114,
        "object_id": 618,
        "objectmaplogs": [],
        "sync_required": null
      }

   4. The ObjectMap for the chapter will have two different schemas. This difference in schema might relates to how the chapters were set up - whether they were create a Meetup chapter or linked to one.
2. Organization-level authentication:
   1. If the chapter-level OAuth token is not available or invalid, the code falls back to using the organization-level OAuth token.
   2. The organization-level OAuth token is also stored in an ObjectMap record.

Token refresh

• When the access_token is about to expire (based on the `expires_at` field), the code attempts to use the refresh_token to obtain a new access_token
• The refresh_token is meant to be a longer-lived credential that can be used to request new access_tokens without requiring the user to re-authenticate.

Authentication flow

• When a chapter is first connected to the Meetup integration, an OAuth flow is initiated, and the resulting access_token and refresh_token are stored in the chapter's ObjectMap.
• Similarly, when the organization-level integration is connected, the access_token and refresh_token are stored in the organization's ObjectMap.
• Over time, as the access_tokens expire, the code attempts to use the refresh_tokens to obtain new access_tokens, without requiring the user to re-authenticate.

The key points are:

• The integration supports both chapter-level and organization-level authentication
• The tokens are stored in ObjectMap records
• The refresh_token is used to obtain new access_tokens when the old ones expire
• The code first checks the chapter-level token, and falls back to the organization-level token if the chapter-level token is not available or invalid