ここですという名前のブログやさん

OAuth については、種々解説もありますが、もともと、OAuth という考え方は、「いかに安全に第三者に自分のアカウントへのアクセスを許すか」という点を重視したものです。
ですから、実際のところ、「ユーザーの許可をどう得るか」という点に、多くの機能があてられています。

一方で、Twitter の Bot は、自作のものである限り、Bot の作者も、Bot のアカウントの管理者も同一だと考えて良いでしょう。つあり、はじめから、「ユーザー（この場合は、Bot のアカウント）の許可」はとれているということになります。
そのため、「Twitter で Bot として振る舞う」だけであれば、一般的な OAuth の解説のうち、かなりの部分を省略できます。

【OAuth の「一般的な」手順】

OAuth の解説の中で、一般的な手順は、たとえばこのように書かれています。
（ APIアクセス権を委譲するプロトコル、OAuthを知る http://www.atmarkit.co.jp/fsecurity/special/106oauth/oauth02.html より、記述はかなり省略してあります）

１．コンシューマ登録
（1） コンシューマは、APIを通じたユーザーリソースの利用者としてサービスプロバイダへ登録を要求する。
（2） サービスプロバイダは、「コンシューマ・シークレット」をコンシューマに発行する。

２．リクエスト・トークン要求とユーザーの同意確認
（1） ユーザーはコンシューマのサービスを利用するために、Webブラウザでコンシューマにアクセスする。
（2） コンシューマはサービスプロバイダに接続して「リクエスト・トークン」の発行を要求する。
（3） サービスプロバイダは未承認の（Unauthorized）リクエスト・トークンをコンシューマに返す。
（4） コンシューマは、リクエスト・トークンにユーザーの承認を取るために、をサービスプロバイダにリダイレクトする。
（5） サービスプロバイダはユーザーにコンシューマがアクセスするユーザーリソースの内容と条件を表示し、同意の確認を促す。
（6） ユーザーの同意が取れたら、リクエスト・トークンを「承認（Authorized）」にして、コンシューマへリダイレクトして返す。

３．アクセス・トークン要求とAPI接続
（1） コンシューマは「アクセス・トークン」の発行を要求する。
（2） サービスプロバイダはアクセス・トークンと「トークン・シークレット」をコンシューマに返す。
（3） コンシューマはAPIに接続を要求する。
（4） サービスプロバイダはそれぞれのパラメータの値を確認し、問題がなければ、APIの応答データをコンシューマに返す。

これをすべてこなすのはかなり大変です。

【Twittter の Bot として振る舞う際に、最低限必要な手順】

１．コンシューマ登録
（1） コンシューマは、APIを通じたユーザーリソースの利用者としてサービスプロバイダへ登録を要求する。
（2） サービスプロバイダは、「コンシューマ・シークレット」をコンシューマに発行する。

３．アクセス・トークン要求とAPI接続
（1） コンシューマは「アクセス・トークン」の発行を要求する。
（2） サービスプロバイダはアクセス・トークンと「トークン・シークレット」をコンシューマに返す。
（3） コンシューマはAPIに接続を要求する。
（4） サービスプロバイダはそれぞれのパラメータの値を確認し、問題がなければ、APIの応答データをコンシューマに返す。

以上です。２．項が丸ごと抜けてしまいました。
これでもちょっと大変……という気がしますが、実運用は（Bot に限定すれば）それほどでもありません。

既に書きましたが、
（Bot 用、Access Token、Access Token Secret 入手法 http://asano-nagi.sblo.jp/article/37853895.html ）
Twitter にログインした状態で、簡単に入手できるわけです。

これをふまえてさらに書き換えると

【Twitter の Bot として振る舞う際に、最低限必要な手順 ―― Twitter にログインして】

１．準備
（１）コンシューマ登録をし、Consumer key, Consumer secret を取得する （上記「入手方法」の１．〜５．）
（２）その後、My Account Toke をクリックして、Access Token と、Access Token Secret を取得する。
　　　（上記「入手方法」の６．〜８．）

２．Bot として動作するとき
（１）OAuth 認証ヘッダを作成する。
（２）それを使って認証を行う。

以上に集約できます。

OAuth 認証ヘッダについては、次の機会に。